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This application claims the benefit of the filing date of U.S. Provisional Application No. 
60/230,054, entitled "Development Tool for Modeling Workflow," filed on September 1, 2000, 
5 and U.S. Provisional Application No. 60/296,707, entitled "Improved Development Tool For 
Modeling Workflow," filed on June 7, 2001, both of which are incorporated herein by reference. 

The following identified U.S. patent applications are also relied upon and are 
incorporated by reference in this application: 

U.S. Patent Application No. , entitled "Methods and Systems for 

10 Integrating Process Modeling and Project Planning," bearing attorney docket no. TS1000, and 
filed on the same date herewith; 

U.S. Patent Application No. , entitled "Methods and Systems for 

Animating a Workflow and a Project Plan," bearing attorney docket no. TS1005, and filed on 
% the same date herewith; and 

|§ U.S. Patent Application No. , entitled "Methods and Systems for 

CO Optimizing Resource Allocation Based on Data Mined from Plans Created from a Workflow," 
f bearing attorney docket no. TS 1 006, and filed on the same date herewith. 

|f) Field Of The Invention 

H= The present invention relates to a method and system for developing a workflow and 

creating project plans from the workflow. More particularly, the invention relates to a method 
and system for improving a workflow based on data mined from project plans created from the 
workflow. 

25 Background Of The Invention 

To become more efficient and competitive, businesses and industries have striven to 
capture and streamline the business processes or workflows they use to operate and manage their 
respective enterprises. In general, a workflow is a model of a process. More specifically, a 
workflow can be viewed as a structured set of activities designed to produce a specific output for 

30 a particular customer (internal or external to an enterprise) or market. Although conventional 

software tools define the steps performed by the workflow, conventional tools do not schedule 
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the resources (e.g., the people, equipment, or software technologies) responsible for completing 
each activity. Conventional tools also do not prepare a timeline identifying the beginning or end 
of each activity. Thus, conventional tools do not prepare a schedule for completing the 
workflow. 

5 Businesses and industries also use other conventional software tools, such as Microsoft 

Project™, to build and manage a project plan for their respective enterprises. A plan represents 
an instance of the workflow. More specifically, a plan can be viewed as a working schedule for 
a project to produce a product or artifact, such as a computer, bicycle, or software build, for the 
respective enterprise. These other conventional software tools typically display the working 
10 schedule in the form of an interactive Gantt chart, i.e., a chart to which the user can make 
updates. A Gantt chart is the linear, time-based representation of a project schedule, usually laid 
out on a horizontal plane where the times/dates increase to the right. These Gantt charts show 
the temporal relationships between the different tasks in a project, where the tasks are arranged 
1 along the vertical axis. Gantt charts are typically used to lay out an initial plan/timeline for the 
if project, and then to track the actual progress of a project from start to finish. The modern 
; software-based Gantt chart also identifies the resource(s) responsible for completing each task of 
~ the plan, the dependencies between the tasks, and, once the project has begun, the status of each 
task. 

z The conventional tools that support the building and managing of a project plan, 

20 however, do not provide direct links between projects and the workflows or business processes 
1 that the enterprise has defined and seeks to implement to gain business advantage and 
economies of efficiencies. Likewise, the conventional tools that enterprises use to define and 
manage workflows are not linked to project plans. Because both workflows and project plans do 
not exist on the same tool, workflows and project plans cannot be integrated or synchronized to 
25 keep the workflows and project plans "in step" with each other. Thus, there is a need in the art 
for a tool that avoids the limitations of these conventional software tools. 

Summary Of The Invention 

Methods and systems consistent with the present invention provide a workflow modeling 
and project planning integration tool that overcomes the limitations of conventional tools. 
30 Contrary to conventional tools that do not allow a user to integrate a business process or 
workflow with a project plan, the integration tool, in accordance with methods and systems 



consistent with the present invention, allows a user to model a business process or workflow, to 
create and activate or start a project plan based on the workflow, to manage the execution of the 
activated plan, and to track the progress of the activated project plan. In addition, the tool may 
include a Web-based "Distributed Authoring and Versioning" server that operates as a virtual 
5 file system to allow more than one user to view the same workflow or project plan, to provide 
persistent storage, to monitor the progress of an activated project plan, to simultaneously create 
plans from the same workflow, and to have essentially unlimited access to the power of the tool 
through the ubiquity of the Internet. "Versioning is a term well-known in the art for capturing 
the state of an entity at given points in time. 
10 In accordance with methods consistent with the present invention, a method is provided 

in a data processing system. The data processing system has a workflow that models a process. 
The data processing system also has a plan that reflects an instance of the process and that has 
been created from the workflow. The method initiates execution of the plan such that the 
= instance of the process is at least partially performed, receives a characteristic about the at least 
L-5 partial performance of the plan, and modifies the workflow to reflect the characteristic so that a 
12 subsequent plan created from the modified workflow has the received characteristic. 

In accordance with methods consistent with the present invention, a method is provided 
_ in a data processing system. The data processing system has a workflow that models a process. 
- The data processing system also has plans that reflect instances of the process and that have been 
20 generated from the workflow. The method receives a modification to a characteristic of at least 
~Z one of the plans, determines whether a number of the modified plans exceeds a predefined 

threshold, and when it is determined that the number exceeds the predefined threshold, performs 
the modification on the workflow. 

In accordance with methods consistent with the present invention, a method is provided 
25 in a data processing system. The data processing system has a workflow that models a process. 
The data processing system also has plans that reflect instances of the process and that have been 
generated from the workflow. The method initiates execution of each plan such that instances of 
the process are at least partially performed, receives a characteristic about the performance of at 
least one of the plans that is inconsistent with the workflow, determines whether a number of the 
30 inconsistent plans exceeds a predefined threshold, and when it is determined that the number 

exceeds the predefined threshold, modifies the workflow to reflect the inconsistent characteristic 
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of the at least one of the plans so that a subsequent plan created from the modified workflow has 
the inconsistent characteristic. 

In accordance with articles of manufacture consistent with the present invention, a 
computer-readable medium is provided. The computer-readable medium contains instructions 
5 for controlling a data processing system to perform a method. The data processing system has a 
workflow that models a process. The data processing system also has a plan that reflects an 
instance of the process and that has been created from the workflow. The method comprising 
the steps of initiating execution of the plan such that the instance of the process is at least 
partially performed, receiving a characteristic about the at least partial performance of the plan, 

1 0 and modifying the workflow to reflect the characteristic so that a subsequent plan created from 
the modified workflow has the received characteristic. 

In accordance with articles of manufacture consistent with the present invention, a 

z! computer-readable medium is provided. The computer-readable medium contains instructions 
for controlling a data processing system to perform a method. The data processing system has a 

if workflow that models a process. The data processing system also has plans that reflect instances 
of the process and that have been generated from the workflow. The method comprising the 
steps of receiving a modification to a characteristic of at least one of the plans, determining 
whether a number of the modified plans exceeds a predefined threshold, and when it is 
determined that the number exceeds the predefined threshold, performing the modification on 

20 the workflow. 

In accordance with articles of manufacture consistent with the present invention, a 
computer-readable medium is provided. The computer-readable medium contains instructions 
for controlling a data processing system to perform a method. The data processing system has a 
workflow that models a process. The data processing system also has plans that reflect instances 

25 of the process and that have been generated from the workflow. The method comprising the 
steps of initiating execution of each plan such that instances of the process are at least partially 
performed, receiving a characteristic about the performance of at least one of the plans that is 
inconsistent with the workflow, determining whether a number of the inconsistent plans exceeds 
a predefined threshold, and when it is determined that the number exceeds the predefined 

30 threshold, modifying the workflow to reflect the inconsistent characteristic of the at least one of 
the plans so that a subsequent plan created from the modified workflow has the inconsistent 
characteristic. 
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Other systems, methods, features and advantages of the invention will be or will become 
apparent to one with skill in the art upon examination of the following figures and detailed 
description. It is intended that all such additional systems, methods, features and advantages be 
included within this description, be within the scope of the invention, and be protected by the 
5 accompanying claims. 



Brief Description Of The Drawings 

The accompanying drawings, which are incorporated in and constitute a part of this 
specification, illustrate an implementation of the present invention and, together with the 
description, serve to explain the advantages and principles of the invention. In the drawings: 

Fig. 1 depicts a data processing system suitable for practicing methods and systems 
consistent with the present invention; 

Fig. 2 depicts an architectural overview of the workflow modeling and project planning 
integration tool used to perform methods and systems consistent with the present invention; 

Fig. 3 depicts a flow diagram illustrating the high-level process performed by the tool of 
Fig. 2 in accordance with methods and systems consistent with the present invention; 

Fig. 4 depicts an exemplary document workflow modeled by an enterprise affiliate using 
the tool of Fig. 2; 

Fig. 5 depicts an exemplary task workflow modeled by an enterprise affiliate using the 
tool of Fig 2; 

Fig. 6 depicts another exemplary workflow modeled by an enterprise affiliate using the 
tool of Fig 2; 

Fig. 7 depicts a timeline of the task created from the workflow of Fig. 4; 
Fig. 8 depicts a timeline of the task created from the workflow of Fig. 5; 
Fig. 9 depicts a timeline of the task created from the workflow of Fig. 6; 
Figs. 10-12 depict the execution of the plan depicted in Fig. 7; 
Figs. 13-16 depict the execution of the plan depicted in Fig. 8; 

Figs. 17-21 depict the execution of the plan depicted in Fig. 9 following the default path; 
Figs. 22-27 depict the execution of the plan depicted in Fig. 9 following the non-default 

path; 

Figs. 28A-C depict a flow diagram illustrating the creation or retrieval of a workflow by 
the tool of Fig. 2; 



Fig. 29 depicts an exemplary user interface of the tool of Fig. 2 used to begin creating or 
retrieving a workflow; 

Fig. 30 depicts an exemplary user interface of the tool of Fig. 2 used to enter the name of 
a new workflow group; 

5 Fig. 31 depicts an exemplary user interface of the tool of Fig. 2 used to begin creating a 

new workflow; 

Fig. 32 depicts an exemplary user interface of the tool of Fig. 2 used to enter the name of 
a new workflow; 

Fig. 33A-C depict an exemplary workflow definition file produced by the tool of Fig. 2 
1 0 for the workflow depicted in Fig. 6; 

Fig. 34 depicts an exemplary user interface of the tool of Fig. 2 used to manage a 
workflow; 

D Fig. 35 depicts an exemplary user interface of the tool of Fig. 2 used to add a new role to 

3 a workflow; 

:6 Fig. 36 depicts an exemplary user interface of the tool of Fig. 2 used to select an artifact 

Q type; 

p: Fig. 37 depicts an exemplary user interface of the tool of Fig. 2 used to enter condition 

£ = properties for a document-oriented artifact; 

fig Fig. 38 depicts an exemplary user interface of the tool of Fig. 2 used to enter condition 

|D properties for a script-oriented artifact; 

O Fig. 39 depicts an exemplary user interface of a script editor for the tool of Fig. 2; 

Fig. 40 depicts an exemplary user interface of the tool of Fig. 2 used to modify the 
properties of a workflow activity; 

Figs. 41 A and B depict a flow diagram illustrating the creation of a plan from a 
25 workflow; 

Fig. 42 depicts an exemplary user interface of the tool of Fig. 2 used to create a new plan 

group; 

Fig. 43 depicts an exemplary user interface of the tool of Fig. 2 displaying the available 
plan groups; 

30 Fig. 44 depicts an exemplary user interface of the tool of Fig. 2 used to enter a plan 

name; 
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Fig. 45 depicts an exemplary user interface of the tool of Fig. 2 used to enter the working 
schedule; 

Fig. 46 depicts an exemplary user interface of the tool of Fig. 2 used to enter the 
scheduled start and end times for the plan; 
5 Fig. 47 depicts an exemplary workflow definition file produced by the tool of Fig. 2 for 

the workflow of Fig. 5 is created; 

Fig. 48 depicts an exemplary plan definition file created from the workflow definition 
file of Fig. 47; 

Fig. 49 depicts an exemplary user interface of the tool of Fig. 2 used to assign users to a 

10 plan; 

Fig. 50 depicts an exemplary user interface of the tool of Fig. 2 used to edit the 
properties of a plan; 

77 Fig. 51 depicts a timeline of the task created from the workflow of Fig. 5; 

£ Fig. 52 depicts an exemplary timeline of the tool of Fig. 2 used to activate apian; 

f 5 Fig. 53 depicts a flow diagram illustrating the addition of a resource by the tool of Fig. 2; 

"I Fig. 54 depicts an exemplary user interface of the tool of Fig. 2 used to add a resource; 

Fig. 55 depicts an exemplary user interface of the tool of Fig. 2 used to receive LDAP 
access information; 

_r Fig. 56 depicts an exemplary resource file created by the tool of Fig. 2; 

20 Fig. 57 depicts a flow diagram illustrating the management of an activated plan; 

= Fig. 58 depicts a timeline of the task created from the workflow of Fig. 5; 

Fig, 59 depicts an exemplary plan definition file created from the workflow of Fig. 5; 

Figs. 60, 62, 64 and 66 depict the actual timeline showing the execution of the plan 
depicted in Fig. 58; 

25 Figs. 61, 63, and 65 depict the properties of the executing tasks of Figs. 62, 64, and 66; 

Figs. 67A-D depict a flow diagram illustrating an exemplary process performed by the 
Client Interface in Fig. 1 to improve a workflow created by the Client Interface; 

Fig. 68 depicts an excerpt of exemplary workflow definition file created by the Client 
Interface; 

30 Fig. 69 depicts an exemplary graphical representation displayed by the Client Interface to 

reflect the workflow definition file in Fig. 68; 
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Fig. 70 depicts an exemplary user interface displayed by the Client Interface for 
receiving one or more conditions-to-check in a task created from a "Get Parts" activity in 
workflow definition file in Fig. 68; 

Figs. 71 A-B depict an excerpt of an exemplary plan definition file that was created from 
5 the workflow definition file in Fig. 68 by the Client Interface; 

Fig. 72 depicts actual-start-date and actual-finish-date properties stored by the Client 
Interface for the "Get Parts" task in the plan definition file in Fig. 71 A-B; 

Figs. 73A-C depict an excerpt of another exemplary plan definition file created by the 
Client Interface in response to an enterprise affiliate assigning a replacement resource to a task 
10 role of "Get Parts" task in the plan definition file in Fig. 71 A-B; 

Fig. 74 depicts actual-start-date and actual-finish-date properties stored by the Client 
Interface for the "Get Parts" task in the other plan definition file in Figs. 73A-C;. 
Q Fig. 75 depicts an excerpt of another exemplary workflow definition file created by the 

% Client Interface to reflect the optimization of the workflow definition file in Fig. 68 for a 
f5 duration-tolerance-exceeded condition; 

q Fig. 76 depicts an excerpt of a workflow roles file created by the Client Interface to store 

= I role profiles for roles assigned to activities in the workflow definition file in Fig. 68; 
: ~_ Fig. 77 depicts a resource file created by the Client Interface to store resource profiles for 

resources that may be assigned by the Client Interface to roles of tasks created from activities in 
2jp the workflow definition file in Fig. 68; 

3 Fig. 78 depicts an excerpt of another exemplary workflow definition file created by the 

Client Interface to reflect the optimization of the workflow definition file in Fig. 68 for a 
role/resource reassignment condition; 

Fig. 79 depicts an excerpt of another workflow roles file created by the Client Interface 
25 to store role profiles for roles assigned to activities in the workflow definition file in Fig. 68; 

Fig. 80 depicts an exemplary graphical representation of the workflow definition 
displayed by the Client Interface to reflect the optimization of the workflow definition file in 
Fig. 78 for a new-successor condition; 

Figs. 81A-C depict an excerpt of another exemplary plan definition file created by the 
30 Client Interface in response to an enterprise affiliate manually assigning a new-successor to "Get 
Parts" task in the plan definition file in Fig. 73A-C, where the new-successor corresponds to an 
activity in the workflow definition file in Fig. 78; 



Fig. 82 depicts an excerpt of another exemplary workflow definition file created by the 
Client Interface to reflect the optimization of the workflow definition file in Fig. 78 for a new- 
successor condition; 

Fig. 83 depicts an exemplary graphical representation displayed by the Client Interface to 
5 reflect the optimization of the workflow definition file in Fig. 82 for the new-successor 
condition; 

Figs. 84A-C depict an excerpt of another exemplary plan definition file created by the 
Client Interface in response to an enterprise affiliate manually adding a new-successor to "Get 
Parts" task in the plan definition file in Fig. 73A-C; 
10 Fig. 85 depicts an excerpt of another exemplary workflow definition file created by the 

Client Interface to reflect the optimization of the workflow definition file in Fig. 78 for a new- 
successor condition; and 

□ Fig. 86 depicts an exemplary graphical representation displayed by the Client Interface to 

% reflect the optimization of the workflow definition file in Fig. 85 for the new-successor. 

ii~5 Detailed Description Of The Invention 

m Methods and systems consistent with the present invention provide an integrated 

^ workflow modeling and project planning integration tool that improves the efficiency and 
O reduces the operating cost of an enterprise or business conglomerate. Contrary to conventional 
_2 tools that do not allow a user to integrate a workflow and a project plan, the integration tool 
2P allows a user to model a business process or workflow, to create and activate a project plan 
H based on the workflow, and to track the progress of the activated project plan. The tool also 
allows the workflow to be reused to create more than one project plan based on the workflow. 
The tool simultaneously manages the execution of the plans. Moreover, the integration tool may 
include a virtual file system server, such as a Web-based "Distributed Authoring and 
25 Versioning" (WebDAV) server that operates as a virtual file system for computers on a network. 
With the WebDAV server, more than one user on different computer systems may view the 
same workflow or project plan, monitor the progress of an activated project plan, or 
simultaneously create and activate different plans from the same workflow. 



System Overview 

30 While methods and systems consistent with the present invention may apply to any 

enterprise in any industry, they will be further described below with reference to the software 
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industry to provide clarity, consistency, and to demonstrate the invention as applied to one of the 
more difficult process industries. More particularly, methods and systems consistent with the 
present invention will be described with reference to a software development business process 
that is applicable to the software industry. 
5 Fig. 1 depicts a data processing system 100 suitable for practicing methods and systems 

consistent with the present invention. Data processing system 100 includes a group of 
computers 102a, 104, and 106 that are connected via a network 108. Network 108 may be any 
known physical or wireless network capable of supporting a data transmission between two 
computer systems, such as a Local Area Network (LAN), a Wide Area Network (WAN), the 

1 0 Internet, or leased phone lines. 

As further explained herein, computer 102a may actually be one of multiple computers 
(i.e., computers 102a and 102n) used by affiliates of an enterprise or business conglomerate to 
communicate with one another via network 108. The enterprise affiliates may be employees, 
managers, administrators, suppliers, customers, other computer applications, other computer 

t-5 systems, or other users within the enterprise who may need to create, view, or receive 
information regarding an activated project plan in accordance with methods and systems 
consistent with the present invention. 

Each computer 102a, 104, and 106 includes a memory (110, 1 12, and 114, respectively), 
- a secondary storage device (116, 118, and 120, respectively), an I/O device (122, 124, and 126, 

2j0 respectively), and a processor (128, 130, and 132, respectively). Memory 1 10 in computer 102a 

~Z includes a Client Interface 134 to a Web-based "Distributed Authoring and Versioning" 
(WebDAV) server 140 in memory 1 12. Client Interface 134 has Process and Plan modules 136 
that collectively allow an enterprise affiliate to create a reusable workflow and to create and 
activate a proj ect plan based on the reusable workflow. 

25 Memory 110 in computer 102a also includes a target processor interpreter, such as a 

Java™ Virtual Machine 138. To permit the Client Interface 134 to run on most any computer, 
the Client Interface 134 may be developed using the Java™ Programming Language. Thus, 
Client Interface 134 may include Java™ bytecodes. The Java™ Virtual Machine 138 interprets 
the Java™ bytecodes of the Client Interface 134 so that the Client Interface 134 may execute on 

30 computer 102a. 

The WebDAV server 140 in memory 112 of computer 104 operates as a virtual file 
system for computers 102a, 102n, and 106 on the network 108. To operate as a virtual file 
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system, WebDAV Server 140 communicates on the network 108 using the WebDAV protocol, 
and stores files on WebDAV storage 142. In one implementation, WebDAV storage 142 may 
be a known database, such as Oracle, DB2, MS Structured Query Language (SQL) storage, or 
any Java Database Connectivity (JDBC)-compliant database. In this implementation, WebDAV 
5 Server 140 includes a database management system (DBMS) or a JDBC interface to control 
access to the WebDAV storage 142. 

In accordance with methods and systems consistent with the present invention, two 
separate enterprise affiliates using their respective Client Interfaces 134 on their respective 
computers 102a and 102n may independently request and view the same workflow or plan 

10 stored on WebDAV Storage 142. In addition, the Client Interface 134 allows any enterprise 
affiliate to create, delete, move, and copy workflows, project plans, and associated 
roles/resource lists on WebDAV server 140. Furthermore, properties of a process, a plan, or a 

O task of a plan may be added, located, or changed on WebDAV Storage 142 by Client Interface 

% 134 using known methods of the WebDAV protocol. 

;fe The WebDAV protocol is a set of known extensions to the standard HyperText Transfer 

O protocol (HTTP) that allows enterprise affiliates using client computers 102a and 102n to 
collaboratively store, edit, and manage files remotely on a Web Server, such as WebDAV Server 
■■^ 140 using network 108. As known to one skilled in the art, HTTP defines how messages sent to 
m or from a Web server on the Internet are formatted and transmitted. HTTP also defines what 
j£b actions a Web server or Web browser of a computer on the Internet should take in response to 
O various commands submitted as part of an HTTP message. 

The WebDAV protocol defines a WebDAV resource to be a collection (e.g., a directory 
or folder on WebDAV Storage 142) or a collection member (e.g., a file or Web page on 
WebDAV Storage 142). Each WebDAV resource has a content file and properties associated 
25 with the content file. The properties include the creation date, the author, and the access rights 
for the WebDAV resource. The WebDAV protocol specifies the methods to create, delete, 
move, and copy a WebDAV resource. It also specifies the methods to add, find, or change a 
property of a WebDAV resource. The WebDAV protocol and the HTTP extensions that 
comprise the WebDAV protocol are more clearly described in the following reference, which is 
30 incorporated herein by reference: HTTP Extensions For Distributed Authoring — WebDAV, 
RFC 2518, Standards Track, Proposed Standard, February 1999, available at 
http://andrew2.andrew.cmu.edu/rfc/rfc25 1 8.html. 



Memory 1 14 in computer 106 includes a Tool Server 144. The Tool Server 144 includes 
a WebDAV proxy 146 and Management Modules 148. WebDAV proxy 146 mediates 
communication between the Client Interface 134 and the WebDAV server 140. The messages 
or requests directed to the WebDAV server 140 from the Client Interface 134 are initially sent to 
5 the WebDAV proxy 146, as discussed in detail below. The WebDAV proxy 146 passes these 
messages and requests to the Management Modules 148. Each of the Management Modules 148 
is configured to inform the WebDAV proxy 146 when a message or request has been serviced. 
If none of the Management Modules 148 services the message or request, then the WebDAV 
proxy 146 sends the message or request to the WebDAV Server 140 via the network 108. If, on 

10 the other hand, the Management Modules 148 are able to service the message or request, the 
message or request is not sent to the WebDAV Server 140. The types of messages or requests 
serviced by the Management Modules 148 include activating a project plan, notifying various 

o enterprise affiliates assigned to each task of the plan, and managing the execution of the plan to 

.J the enterprise affiliates. 

:|l5 In another implementation, memory 114 in computer 106 includes a WebDAV servlet 

Q (not shown), which is an application designed to perform as a WebDAV Engine in lieu of 
~: WebDAV Server 140. The WebDAV servlet may be started by and executed within the Tool 
®_ Server 144. In this implementation, WebDAV servlet is persistent. Thus, once WebDAV 
m servlet is started, it stays in memory and can fulfill multiple requests. WebDAV servlet is 
iSO configured to control access to WebDAV Storage 142, which may be included in secondary 
P storage 120 in computer 106. 

Memory 114 in computer 106 also includes a target processor interpreter, such as a 
Java™ Virtual Machine 150. As with the Client Interface 134 on computer 102a, the Tool 
Server 144 includes Java™ bytecodes that the Java Virtual Machine 150 interprets so that the 
25 Tool Server 144 may execute on computer 106. 

In another implementation, the data processing system 100 may operate in a local host 
configuration rather than across the network 108. In this implementation, the memory 110 of 
computer 102 a may include the Tool Server 144 and the WebDAV Server 140. In addition, the 
secondary storage device 116 may include the WebDAV Storage 142. 
30 Although aspects of the present invention are described as being stored in memory, one 

skilled in the art will appreciate that these aspects can also be stored on or read from other types 



12 



of computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or 

CD-ROM; a carrier wave from a network, such as Internet; or other forms of RAM or ROM. 

Fig. 2 depicts a functional architectural overview of the workflow modeling and project 

plarining integration tool 200 used to integrate workflow modeling and project planning. As 
5 shown in Fig. 2, the tool 200 includes the Client Interface 134 as well as the Tool Server 144. 

Although part of the same tool 200, the Client Interface 134 and the Tool Server 144 may be 

located on different computer systems, as discussed above. 

The Client Interface 134 includes a Virtual File System ("VFS") Interface 202 that is 

configured to allow the Client Interface 134 to connect to the secondary storage device 116 for 
10 local file access or to connect to the WebDAV Storage 142 via the WebDAV proxy 146 for 

virtual file access. To allow the WebDAV proxy 146 to mediate communication between the 
. Client Interface 134 and the WebDAV Storage 142, the VFS Interface 202 is configured to send 
Z the virtual file access requests from the Client Interface 134 to a Uniform Resource Locator 
~~ (URL) or network address for the WebDAV proxy 146. For example, the URL for the 
15 WebDAV proxy 146 may be "http://www.ToolServer.comAVebDAVproxy." A URL typically 

consists of an access protocol (e.g., http), a domain name (e.g., www.ToolServer.com), and, 
~ optionally, the path to a file or resource residing on that server (e.g., WebDAVproxy). If the Tool 

Server 144, where the WebDAV proxy 146 is located, has an IP address of 192.168.5.1 and an 

assigned port address of 8088, then the URL for the WebDAV proxy translates to 
20 "http://l 92. 1 68.5. 1 :8088/WebDAVproxy." 

~Z As discussed above, the VFS Interface 202 initially sends the requests that the Client 

Interface 134 directs to the WebDAV Storage 142 to the WebDAV proxy 146. The WebDAV 
proxy 146 sends these requests to the Management Modules 148. After the Management 
Modules 148 review these requests, the WebDAV proxy 146 sends the request to the WebDAV 

25 server 140 if the Management Modules 148 do not respond to the requests from the Client 
Interface 134. If the request is to be sent to the WebDAV server 140, the Tool Server 144 
directs the request to a URL or network address for the WebDAV server 140. 

The Client Interface 134 also includes a module loader 204 to load the Process and Plan 
modules 136. As one skilled in the art will appreciate, Client Interface 134 may be developed so 

30 that the functionality provided by Process and Plan modules 136 is not loaded by a known 
module loader 204, but integrally incorporated within the element corresponding to the Client 
Interface 134. The Process and Plan modules 136 produce the requests to store or modify the 
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various client files on the WebDAV storage 142. As further described below, the various types 
of client files include a condition model, a user profile, a resource profile, a workflow definition 
file, and a plan definition file. Each of these files has properties defined in accordance with the 
WebDAV protocol. The various types of client files follow a schema or document type 
5 definition that is known to the Tool Server 144 so that the Tool Server 144 can identify the type 
of client file sent by the Client Interface 134 and intercepted by the WebDAV Proxy 146. In 
addition, each type of client file has a unique identifier, such as a URL network address, which 
the Tool Server 144 may use to locate the associated client file for processing. The various 
types of client files are discussed in context with the general description of the Process and Plan 

10 modules 136 and also further discussed with the implementation details of creating a workflow 
and a project plan from the workflow. Although XML files are used to represent the client files 
used with methods and systems consistent with the present invention, one skilled in the art will 

D recognize that any file type can be used to represent the client files. 

yg The Process and Plan Modules 136 include a Resource Manager Module 206, an 

rfe Activity I/O Condition Designer Module 208, a Process Designer Module 210, a Project Plan 
O Manager Module 212, and a Task Tracker Module 214. The Resource Manager Module 206 
Li allows an enterprise affiliate with system administrative privileges or permissions, such as a 
L project manager, to create, modify, and store a user profile for an enterprise affiliate. The user 
■S profile identifies the access control rights that are associated with the enterprise affiliate, such as 
flO whether the enterprise affiliate may create or edit or delete a project plan based on a workflow or 
J=f whether the enterprise affiliate is limited to viewing an existing workflow or plan. When the 
Client Interface 134 sends a request to the WebDAV Server 140 to store the user profile, the 
Client Interface 134 may specify that the user profile be stored with a unique identifier so that 
the Tool Server 144 may later locate the user profile for further processing. For example, the 
25 Client Interface 134 may request that the unique identifier be a location or URL where the user 
profile is to be stored on the WebDAV Storage 142. If the unique identifier is stored as a 
property of the user profile on the WebDAV storage 142, the Client Interface 134 sends a 
request to the WebDAV Server 140 to set the value of the property. 

The Resource Manager Module 206 also allows an enterprise affiliate to create, modify, 
30 and store the role profiles that may be assigned to an activity of a workflow that is modeled 
using the tool 200. The role profile identifies a group of resources that may be assigned to 
complete a task created from the activity. The role profile is a type of client file that the Client 



Interface 134 may store on WebDAV storage 142 with a unique identifier (e.g., a URL for the 
role profile) to locate the role profile at a later time. A role profile may include a Rolename that 
represents a "capability" or "skill set" for the role. For example, using methods and systems 
consistent with the present invention, an enterprise affiliate may identify one of the following 
Rolenames to the Resource Manager Module 206 so that the associated role profiles are later 
available to assign when defining a software development process: Manager, Analyst, Software 
Architect, Software Developer, Tester, Hardware Architect, and Editor. 

In addition to the above, the Resource Manager Module 206 further allows an enterprise 
affiliate to create, modify, and store the resource profiles (e.g., the person, equipment, or 
systems, such as a development facility) that may be assigned to a task of a plan created from a 
workflow. The resource profile includes a resource ID and a unique identifier for the role 
profile so that the Client Interface 134 may communicate to the Tool Server 144 that the 
identified resource has skills or capabilities corresponding to the role profile. For example, 
when the resource is a person, the Tool Server 144 may recognize that the person can play a 
given role (e.g., Analyst) in a specific activity (e.g., Requirements Analysis) in a workflow (e.g., 
Software Development Process) based on the skills or capabilities required by the role assigned 
to the activity to be performed. 

The Activity I/O Condition Designer Module 208 allows an enterprise affiliate, such as a 
manager, to define a condition model, i.e., an input condition or an output condition, for an 
activity of a workflow. The Activity I/O Condition Designer Module 208 stores the condition 
model with a unique identifier so that the Tool Server 144 may later locate the condition model 
for processing, such as when a task of a plan is created from the activity of the workflow, as 
explained below. 

As discussed above, there are two types of workflows: a document workflow and a task 
workflow. Similarly, there are two types of conditions: a document-type condition and a logic- 
type condition. The Activity I/O Condition Designer Module 208 allows the enterprise affiliate 
to create a condition model based on one of these two condition types. The Activity I/O 
Condition Designer Module 208 also allows the enterprise affiliate to assign a document-type 
condition model or a logic-type condition model to an activity when creating the activity in a 
workflow. Each document-type and logic-type condition model has properties defined by the 
enterprise affiliate that created the respective condition model using the Activity I/O Condition 
Designer Module 208. 
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The properties of the document-type condition model include a location property (e.g., a 
URL) identifying the location of the document or artifact being monitored. Thus, when 
executing a task based on an activity, the Client Interface 134 uses the location property to 
notify the resource responsible for the task where to find the document or artifact so that the 
5 resource may complete its task. 

Another property of the document-type condition model is a state property that indicates 
the allowable states of the document or artifact. For example, the document may have the states 
"DRAFT" and "APPROVED." When creating the workflow, the enterprise affiliate assigns one 
of these allowable states as a condition for entry into or exit from the activity (or the task created 
10 from the activity). When the task is activated, the Workflow Engine 222 evaluates whether the 
state property of the document condition satisfies the input or output condition of the activated 
task before starting or closing the task. 
D When creating a logic-type condition model, Activity I/O Condition Designer Module 

J 208 allows the enterprise affiliate to define the properties shown in Table 1. 
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TABLE 1 



Property 


Description 


Name 


The name used to identify the condition. 


Description 


A description of the condition. 


When to 
Check 


This section identifies when and/or how 
often the condition should be checked. 


• Abs. Time 


The condition is checked when this 
absolute time (calendar time) arrives. 


• Period 


Integer expression in Javascript that 
defines the periodicity of condition check, 
where a "1" means once a minute. (If 
absolute time is also specified, then the 
condition should be checked when the 
absolute time arrives and periodically 
thereafter.) 


• URL 

Change 


The condition is checked after URL 
undergoes a property or content change. 


• Task 
Change 


The condition is checked when the task 
that is specified during plan creation 
changes its state (e.g., starts, finishes). 


• Any 

Request 


The condition is checked when any HTTP 
request is detected. 


Script 


The script to run when the condition is 
met. The script must return "true" or 
"false" (a Boolean). Script is an 
extensible method for users to enter in ad 
hoc logic. 



When a plan is created from a workflow, the Client Interface 134 uses the logic-type 
condition model to generate a logic-type condition for entry/exit and the script (e.g., logic 
element) to be performed to determine if the condition is met. For example, the enterprise 
affiliate may indicate to the Activity I/O Condition Designer Module 208 that the condition is to 
check if the task is complete and that the logic to be performed is to check the status property of 
the task. In this case, the user or resource assigned to this task must notify the Client Interface 
134 that the task is complete. In another example, the enterprise affiliate may indicate to the 
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Activity I/O Condition Designer Module 208 that the condition is to check if the task is 
complete and that the logic to be performed is to check for the existence of a file in a specific 
directory folder on WebDAV Storage 142 in order to determine if the task is complete. In this 
case, the user or resource assigned to this task must create or move a file into the specific 
5 directory folder to indicate that the task is complete. 

The Process Designer Module 210 allows an enterprise affiliate to create, modify, and 
store a workflow. When the enterprise affiliate indicates to Process Designer Module 210 that 
the modeled process is to be saved, Process Designer Module 210 produces a workflow 
definition file based on the modeled workflow object. Client Interface 134 then sends as the 

10 workflow definition file as a client file to WebDAV Server 140 to be stored on WebDAV 
Storage 142. Each workflow definition file produced by Process Designer Module 210 includes 
a unique identifier (e.g., a URL for the workflow definition file) so that Tool Server 144 may 

O later locate the workflow definition file corresponding to the modeled workflow for further 

Jj processing. 

:|5 Project Plan Manager Module 212 allows an enterprise affiliate to create and activate a 

Q project plan from a workflow definition file. In general, upon request to create a project plan, 
jl Project Plan Manager Module 212 sends a query message to the WebDAV Server 140 for the 
!^ workflow definition files contained in WebDAV Storage 142. As further described below, 
ffi Project Plan Manager Module 212 receives the workflow definition files, allows the enterprise 
J |0 affiliate to select one of the workflow definition files to create a project plan, and then produces 
Q a plan definition file based on the selected workflow definition file. When instructed to save the 
plan by the enterprise affiliate, Project Plan Manager Module 212 sends the plan definition file 
as a client file to WebDAV Server 140 to be stored on WebDAV Storage 142. Each plan 
definition file produced by Process Designer Module 210 includes a unique identifier (e.g., a 
25 URL for the plan definition file) so that Tool Server 144 may later locate the workflow 
definition file corresponding to the modeled workflow for further processing. 

The Task Tracker Module 214 allows an enterprise affiliate to view the tasks of an 
activated project plan that are assigned to a specific resource, to activate or start a task of the 
project plan (e.g., indicate actual start time to Client Interface 134), to open or check-out a 
30 document artifact needed to accomplish the task, to close or check-in the document artifact after 
accomplishing the task, and to indicate that the task is completed. 
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The Tool Server 144 includes a module loader 216 to load the Management Modules 
148. Similar to the Client Interface 134, the Tool Server 144 may be developed so that the 
functionality provided by Management Modules 148 is not loaded by a known module loader 
216, but integrally incorporated within the element corresponding to the Tool Server 144. 
5 Management Modules 148 include a User Authorization Module 218, a Resource/Role 
Management Module 220, and a Workflow Engine 222. The Workflow Engine 222 includes a 
Project Plan Management Module 224 and a Project Task Management Module 226. 

When the Client Interface 134 requests access to a client file on the WebDAV Storage 
142, the User Authorization Module 218 verifies that that the enterprise affiliate making the 
10 request has a user profile on the WebDAV Storage 142 with the proper authorization or 
permission to access the requested client file. The User Authorization Module 218 may be 
connected to a Light Directory Access Protocol (LDAP) Import Module 228, which follows a 
3 known LDAP protocol to allow the User Authorization Module 218 to obtain existing user 
J profiles from another computer on network 108. As known to those skilled in the art, an LDAP 
'^5 protocol is based on "entries," where an entry is a collection of attributes that have a 
>1 "distinguished name" (DN). According to the LDAP protocol, directory entries are arranged in 
.* a hierarchical tree-like structure that reflects political, geographic, and/or organizational 
L boundaries. For example, entries representing countries may appear at the top of the tree. The 
lv entries below the countries may represent states or national organizations. Below the states or 
do national organizations may be entries representing people (e.g., user profiles), organizational 
^ units, printers, documents, or any other accessible entity. Each level in the hierarchical tree-like 
structure for the directory entries may be identified by a known standardized keyword, such as 
"CN" for the common name of the entry (e.g., user profile), "L" for locality name, "ST" for state 
or province name, "O" for organization name, "OU" for organizational unit name, and "C" for 
25 country name. The LDAP Import Module 228 uses a DN to refer to the entry unambiguously 
via a concatenation of the hierarchical tree-like structure. After user profiles are retrieved by the 
User Authorization Module 218 via the LDAP import module 228, the user profiles may then be 
stored on the WebDAV Storage 142 by a request from the Client Interface 134. 

The Resource/Role Management Module 220 reviews requests from an enterprise 
30 affiliate to assign a resource to a plan (e.g., to assign a user to a task of the plan). The 
Resource/Role Management Module 220 may check the resource profile corresponding to the 
assigned resource on the WebDAV Storage 142 to verify that the resource is not overloaded. 
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For example, the Resource/Role Management Module 220 determines whether a resource is 
already assigned to another task in another plan during the same time frame, thus preventing it 
from being able to complete one of the tasks to which it is assigned. The Resource/Role 
Management Module 220 may also be connected to the LDAP Import Module 228 to allow the 
Resource/Role Management Module 220 to obtain existing resource profiles from another 
computer on network 108. The resource profiles may also be stored on WebDAV Storage 142 
by a request from Client Interface 134. 

The Workflow Engine 222 reviews requests to activate, deactivate, or update a plan. For 
example, a request to update a plan occurs if the enterprise affiliate who is an owner of a task 
indicates in its request that the task is complete. The Workflow Engine 222 also manages the 
execution of the activated plans. 

High-Level Process 

Fig. 3 depicts a flow diagram illustrating the high-level process performed by the 
workflow modeling and project planning integration tool in accordance with methods and 
systems consistent with the present invention. Initially, the tool creates or retrieves a workflow 
(step 302). The tool then displays the workflow (step 304). The workflow comprises a set of 
activities that represents the steps to be performed as part of a plan executed from the workflow. 
Each activity has an activity description and at least one role responsible for the activity. The 
activity description indicates what step is to be performed by the role. 

There are two types of workflows: a document workflow and a task workflow. In a 
document workflow, the state of one document (or, more generally, any item or artifact) is 
monitored by the activities of the workflow. Thus, a document workflow cannot usually have 
parallel activities, which would require the parallel activities to monitor the states of more than 
one artifact or would require the parallel activities to monitor different states of the same artifact 
simultaneously. The document is in one state at a time. Fig. 4 depicts an exemplary document 
workflow 400. As shown, the workflow 400 includes a start element 402, an end element 404, 
and two activities, "Step 1" 406 and "Step 2" 408. Because "Step 1" 406 occurs directly before 
"Step 2" 408, "Step 1" 406 is the "predecessor activity" to "Step 2" 408. Similarly, "Step 2" 
408 is the "successor activity" to "Step 1" 406. The workflow 400 is used to monitor the state 
of Artifact 410. In particular, in "Step 1" 406, the state of Artifact 410 is "State 1" 412, in "Step 
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2" 408, the state of Artifact 410 is "State 2" 414, and at the end 404 of the workflow, the state of 
Artifact 410 is "Complete" 416. 

A task workflow, on the other hand, typically has no limitations regarding the number of 
artifacts that may be monitored or modified by each activity of the workflow to achieve or 
5 contribute to the business process goal, such as an auditing process that determines if multiple 
accounts are balanced properly. Fig. 5 depicts an exemplary task workflow 500. The task 
workflow 500 includes a start element 502, an end element 504, two serial activities 506 and 
508 and two parallel activities 510 and 512. The workflow also includes two synch bars 514 
and 516, which are used to connect the ends of parallel activities. Contrary to the document 
1 0 workflow, the task workflow allows for parallel activities. 

Another exemplary workflow 600 is depicted in Fig. 6. The workflow 600 includes a 
start element 602 and an end element 604. The first activity of the workflow 600 is "Get Parts" 
O 606, which is followed by a logic activity, "L or Rt Handed?" 608. Logic activities have two 
S successor activities: a "default activity" and a "non-default activity." As the name implies, the 
if 5 workflow generally follows the path of the default activity unless a condition is met in the logic 
O activity, as discussed in detail below. In Fig. 6, the default activity is "Right" 610. The non- 
U default activity is "Left" 612, which is followed by another activity "Left Special" 614. The 
!U default path is represented as a solid connector 6 1 6 while the non-default path is represented as a 
W dotted connector 618. One skilled in the art, however, will recognize that any visible difference 
lJo in the connectors, e.g., a change in type, color, shading, labeling, etc., may be used to represent 
P both the default path as well as the non-default path. Both the default activity 610 and the non- 
default activities 612 and 614 are followed by another activity, "Complete Assembly" 620. In 
addition, though we show only two paths (616 & 618) out of the decision block 608, there could 
be any number of exit paths (not shown). 
25 Returning to Fig. 3, the next step performed by the tool is to create a plan from the 

workflow (step 306). Each activity in the default path of the workflow generally corresponds to 
a task in the plan. The task identifies the scheduled start and stop times for the task. The tool 
then displays the plan (step 308). For example, the plan created from the workflow 400 depicted 
in Fig. 4 is shown in Fig. 7. The plan 700 includes two tasks 702 and 704 that correspond to the 
30 two activities 406 and 408 from the workflow 400. The first task 702 is scheduled to begin at 9 
a.m. 706 on August 1, 2001 (not shown), and end at 6 p.m. 708 on the same day. The second 
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task 704 is scheduled to begin at 9 a.m. 710 on August 2, 2001 (712) and end at 5 p.m. 714 on 
the same day. 

The plan 800 created from the workflow 500 depicted in Fig. 5 is shown in Fig. 8. The 
plan 800 includes two serial tasks 802 and 804 that correspond to the two serial activities 506 
5 and 508 from the workflow 500. The plan 800 also includes two parallel tasks 806 and 808 that 
correspond to the two parallel activities 510 and 512 from the workflow 500. As shown in Fig. 
8, "Serial 1" task 802 is scheduled to begin at 9 a.m. 810 on August 1, 2001 (812) and end at 
5:30 p.m. 814 on the same day. The parallel tasks 806 and 808 are scheduled to start at the 
completion of the "Serial 1" task 802, and are scheduled to end at 6 p.m. 816 on August 2, 2001 
10 (818). The "Serial 2" task 804 is scheduled to begin upon completion of the parallel tasks 806 
and 808 and is scheduled to end at 6 p.m. 820 on August 3, 2001 (822). 

The plan 900 created from the workflow 600 depicted in Fig. 6 is shown in Fig. 9. The 
_ plan 900 includes a task 902 corresponding to the activity "Get Parts" 606, followed by a task 
~~ 904 corresponding to the activity "L or Rt Handed?" 608. The following task 906 corresponds 
15 to the activity "Right" 610. The final task 908 corresponds to the activity "Complete Assembly" 
620. The plan 900 depicts the default path, and does not include any of the tasks corresponding 
to the non-default path. Although the start and end times are not depicted in the plan 900 shown 
in Fig. 9, each task has a scheduled start and stop time. In addition, the tool 200 requires that an 
I" enterprise affiliate assign a resource to each task, as described below. 

20 Returning to the high-level process of Fig. 3, the tool then activates the plan (step 310). 

= Next, the tool manages the execution of the activated plan (step 312). The tool also modifies the 
display of the plan as each task is executed (step 314). The tool then determines whether the 
execution of the plan is complete (step 316). If the execution of the plan is complete, processing 
ends. Otherwise, processing continues to step 312. 

25 For the exemplary plan 700 depicted in Fig. 7, upon activation, the first task 702 begins 

execution. The tool depicts the executing task 1002 by darkening the outer borders of the block 
representing the task 1002, as depicted in the plan 1000 shown in Fig. 10. After completion of 
the task, the tool depicts the executed task 1 102 as a darkened block in the plan 1 100, as shown 
in Fig. 11. At this point, the second task 1104 begins execution, as indicated by the darkened 

30 outer borders of the task 1104. Finally, after both tasks 1102 and 1104 of the plan 1100 have 
been executed, both tasks 1202 and 1204 are depicted as darkened blocks in the plan 1200, as 
shown in Fig. 12. In this embodiment, the tool represents an executing task with darkened 



borders and represents an executed task as a darkened block. One skilled in the art, however, 
will recognize that any visible change in the blocks representing the tasks, e.g., a change in 
shape, color, shading, labeling, etc., may be used to represent the tasks in their various states. 
For example, in another implementation, color may be used to indicate active tasks; for example 
a gray rectangle may be used behind the task to indicate an actual activity since the actual dates 
may not coincide with the dates of the planned task. Thus, the representation of the tasks used 
in the methods, systems, and articles of manufacture consistent with the present invention are 
not limited to those used in the present embodiment. 

The activation and execution of the tasks of the plan 800 depicted in Fig. 8 are shown in 
Figs. 13-16. Fig. 13 depicts the state of the plan 1300 while the "Serial 1" task 1302 is 
executing. Fig. 14 depicts the state of the plan 1400 after execution of the "Serial 1" task 1402, 
while the "Parallel 1" and the "Parallel 2" tasks 1404 and 1406 are executing. Fig. 15 depicts 
the state of the plan 1500 after execution of the "Serial 1" task 1502 and the "Parallel 1" and the 
"Parallel 2" tasks 1504 and 1506, while the "Serial 2" task 1508 is executing. Finally, Fig. 16 
depicts the state of the plan 1600 after execution of the tasks 1602, 1604, 1606, and 1608. 

As discussed above, Fig. 9 represents a plan 900 created from a workflow 600 having a 
logic block 608. The activation and execution of the tasks of the plan 900 following the default 
path are shown in Figs. 17-21, while the activation and execution of the tasks of the plan 900 
following the non-default path are shown in Figs. 22-27. 

Fig. 17 depicts the state of the plan 1700 while the "Get Parts" task 1702 is executing. 
Fig. 18 depicts the state of the plan 1800 after the execution of the "Get Parts" task 1802, while 
the "L Or Rt Handed?" logic task 1804 is executing. The logic task may pop up a dialog (not 
shown) to prompt the resource assigned to this task to provide an answer for this "left or right- 
handed" question. In addition, the tool allows the question to be "answered" by running a logic 
script. This script may examine properties of an indicated artifact or it may execute a separate 
program on a separate system to compute the answer. Upon selection of the default path, the 
plan 1900 shown in Fig. 19 depicts both the "Get Parts" task 1902 and the "L Or Rt Handed?" 
logic task 1904 in executed states, while the "Right" task 1906 is depicted in an executing state. 
After the execution of the "Right" task 1906 is complete, the state of the plan 2000 is depicted in 
Fig. 20 with the "Get Parts" task 2002, the "L Or Rt Handed?" logic task 2004, and the "Right" 
task 2006 in executed states and with the "Complete Assembly" task 2008 in an executing state. 
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Finally, upon completion of the "Complete Assembly" task 2008, the state of the plan 2100 after 
execution of the tasks 2102, 2104, 2106, and 2108 is complete is depicted in Fig. 21. 

Alternatively, if the non-default path is to be chosen, the execution of the plan is initially 
the same as when the default path is chosen. Thus, as depicted in Fig. 22, the plan 2200 begins 
with the execution of the "Get Parts" task 2202. After completion of the "Get Parts" task 2202, 
the plan 2300 shown in Fig. 23 depicts the "Get Parts" task 2302 in an executed state while the 
"L Or Rt Handed?" task 2304 is shown in an executing state. At this point, the resource 
assigned to choose the default or the non-default path chooses the non-default path, thus 
completing the execution of the "L Or Rt Handed?" task 2404, as indicated in Fig. 24. Upon 
selection of the non-default path, the tool 200 modifies the plan 2400 to correspond to the non- 
default path of the corresponding workflow. The plan 2400 depicts the tasks included in the 
non-default path. Thus, the plan 2400 includes the "Left" and "Left Special" tasks 2406 and 
2408 rather than the "Right" task 2306, which is depicted in Fig. 23 before the non-default path 
was chosen. As shown in Fig. 24, the "Left" task 2406 is executing. Fig. 25 depicts the plan 
2500 after the "Get Parts" task 2502, the "L Or Rt Handed?" logic task 2504, and the "Left" task 
2506 have been executed, while the "Left Special" task 2508 is executing. Continuing with the 
execution of the plan, Fig. 26 depicts the state of the plan 2600 after the "Get Parts" task 2602, 
the "L Or Rt Handed?" logic task 2604, the "Left" task 2606, and the "Left Special" task 2608 
are done executing, while the "Complete Assembly" task 2610 is executing. Finally, Fig. 27 
depicts the state of the plan 2700 after completion of the tasks 2702, 2704, 2706, 2708, and 
2710. 

Retrieving Or Creating A Workflow 

Figs. 28A-C depict a flow diagram illustrating an exemplary process for retrieving or 
creating a workflow, i.e., step 302 in Fig. 3. Initially, the tool 200 determines whether to use an 
existing process or workflow group (step 2802). A workflow group is a collection of workflows 
(e.g., a directory or folder containing the collection of workflows) created by the Client Interface 
134 on WebDAV Storage 142. Each workflow group is created by the Client Interface 134 on 
WebDAV Storage 142 with the "workflow group" property as explained further below. When 
creating a workflow, the Client Interface 134 allows the enterprise affiliate to store the workflow 
within an identified workflow group so that any enterprise affiliate using the Client Interface 
134 is able to easily identify related workflows using a hierarchical relationship. For example, 
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software-related workflows may be stored within the same workflow group so that an enterprise 
affiliate is able to quickly locate a desired workflow in order to create a corresponding plan 
using the Client Interface 134. One skilled in the art will appreciate that Client Interface 134 
may store a workflow on WebDAV Storage 142 without associating the workflow with a 
workflow group. 

The tool 200 receives user input from an enterprise affiliate with system administrative 
privileges or permissions, such as a process designer or a project manager, to determine whether 
to retrieve an existing workflow group or to create a new workflow group. If the tool 200 
determines that it will use an existing workflow group, the tool 200 receives an identification of 
the workflow group from the enterprise affiliate (step 2804). In one implementation, the Client 
Interface 134 may retrieve the identifications for the workflow groups on the WebDAV Storage 
142 by requesting that the folders or directories on WebDAV Storage 142 having a "workflow" 
property be returned by the WebDAV Server 140. The Client Interface may use any known 
method in accordance with WebDAV protocol to request that the WebDAV Server 140 return 
any directory or folder on WebDAV Storage 142 that corresponds to a workflow group. The 
tool 200 may then display the available workflow groups to allow the enterprise affiliate to 
select one of the available workflow groups. For example, as shown on the user interface 2900 
depicted in Fig. 29, the tool 200 may display a hierarchical view 2902 of an identified workflow 
group 2904 stored on the root directory 2906 of WebDAV Storage 142. Alternatively, the 
enterprise affiliate may enter the identification of the desired workflow group to the tool 200 for 
retrieval. Using the identification, the tool 200 then retrieves the workflow group (step 2806). 

If the tool 200 determines that a new workflow group will be created, the tool 200 
receives the name of the workflow group from the enterprise affiliate (step 2808). For example, 
the enterprise affiliate may request a new workflow group by clicking on "Process Designer" 
button 2908 of the user interface 2900 depicted in Fig. 29. The enterprise affiliate may, 
alternatively, use any known data input technique, such as an icon or keyboard input, to indicate 
the request to the tool 200. Upon selecting the "Process Designer" button 2908, the tool 200 
displays an exemplary user interface 3000 depicted in Fig. 30 for receiving a new workflow 
group identification 3002 via keyboard input from an enterprise affiliate using computer 102a or 
102n. 

After receiving the new workflow group identification, the tool 200 creates a new 
workflow group in storage (step 2810). For example, the tool 200 may create the workflow 
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group on WebDAV Storage 142. To generate a new workflow group on WebDAV Storage 142, 
the Client Interface 134 sends the WebDAV Server 140 a request to create a new collection or 
folder on WebDAV Storage 142 with the same identification as the new workflow group 
identification 3002. In accordance with WebDAV protocol, the Client Interface 134 receives a 
5 response from the WebDAV Server 140 confirming that the new workflow group folder was 
created on WebDAV Storage 142. As previously discussed, when a new collection or folder is 
created using the WebDAV protocol, the WebDAV properties (e.g., "date of creation," 
"property name" and "lockdiscovery" properties) are created and stored in association with the 
new directory by the WebDAV Server 140. Thus, when generating the new workflow group, 

10 the Client Interface 134 also sets the "property name" of the new workflow group to be 
"workflow group" so that the Client Interface may subsequently use known WebDAV methods, 
such as "PropFind," to retrieve the identification of each workflow group on WebDAV Storage 

O 142. 

5 After retrieving an existing workflow group or creating a new workflow group, the tool 

Jl5 200 determines whether to use an existing workflow (step 2812). The tool 200 receives user 
O input from an enterprise affiliate with appropriate privileges or permissions to determine 
lI whether to retrieve an existing workflow or to create a new workflow. If the tool 200 
5L, determines that it will use an existing workflow, the tool 200 receives an identification of the 
CO workflow from the enterprise affiliate (step 2814). In one implementation, the Client Interface 
2o 134 may retrieve the identifications for the workflows in the selected workflow group and 
5=3 display the available workflows to allow the enterprise affiliate to select one of the available 
workflows. Alternatively, the enterprise affiliate may enter the identification of the desired 
workflow to the tool 200 for retrieval. Using the identification, the tool 200 then retrieves the 
workflow (step 2816). 

25 If the tool 200 determines that a new workflow will be created, the tool 200 receives the 

name of the workflow from the enterprise affiliate (step 2818). For example, the enterprise 
affiliate may request a new workflow by clicking on the desired workflow group 3102 and 
selecting the "New Process" option 3104 from a pull-down menu 3106 on the user interface 
3100 depicted in Fig. 31. The enterprise affiliate may, alternatively, use any known data input 

30 technique, such as an icon or keyboard input, to indicate the request to the tool 200. Upon 
selecting the "New Process" option 3104, the tool 200 may display the exemplary dialog box 
3200 depicted in Fig. 32 to the enterprise affiliate. The enterprise affiliate may then enter the 



name of a new workflow 3202. After receiving the name for the workflow, the tool 200 creates 

the workflow in storage (step 2820). 

Figs. 33A-C depict an exemplary workflow definition file 3300 that is produced by the 

tool 200 when the workflow 600 depicted in Fig. 6 is created. The name 3302 of the workflow, 
5 "Logic Branch Project," is identified in the workflow definition file 3300. Also, as shown in the 

definition file 3300, the workflow 600 does not have a workflow group 3304. The element 3306 

in the workflow definition file 3300 represents the "Get Parts" activity 606. Similarly, the 

element 3308 (Fig. 33C) represents the "L or Rt Handed?" logic activity 608, the element 3310 

represents the "Right" activity 610, the element 3312 represents the "Left" activity 612, the 
10 element 3314 represents the "Left Special" activity 614, and the element 3316 represents the 

"Complete Assembly" activity 620. The start element 602 is represented by the element 3318, 

and the end element 604 is represented by the element 3320. 
□ The next step performed by the tool 200 is to receive an indication of the type of activity 

5 to be created for the workflow (step 2822 in Fig. 28B). As discussed above, the activity may be 
;i5 a standard activity or a logic activity. For example, the workflow 3402 depicted in the user 

interface 3400 of Fig. 34 includes five standard activities 3404, 3406, 3408, 3410, and 3412. 
P The workflow 3402 also includes one logic activity 3414. The selection of the type of activity 
JU may be made by clicking on the icon for a standard activity 3416 or the icon for the logic 
~- activity 3418. Alternatively, any known data input technique, such as a pull-down menu or 
==20 keyboard input, may be used to select the type of activity. 

= After receiving an indication of the type of activity, the tool 200 receives the name of the 

activity (step 2824). The names of the activities depicted in the workflow 3402 are included 
with the activity. Thus, the name of activity 3404 is "Assignment," the name of activity 3406 is 
"Analysis," etc. 

25 Returning to the example workflow 600 depicted in Fig. 6, the name of the first activity 

606 is "Get Parts," which is identified by the element 3322 in the workflow definition file 3300 
of Fig. 33. Similarly, the name of the logic activity 608 is "L or Rt Handed?," which is 
identified by the element 3324. The name of the activity 610 is "Right," as identified by the 
element 3326. The name of the activity 612 is "Left," as identified by the element 3328. The 

30 name of the activity 614 is "Left Special," as identified by the element 3330. Finally, the name 
of the activity 620 is "Complete Activity," as identified by the element 3332. 
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After receiving a name for the activity, the tool 200 receives an indication of the role 
responsible for the activity (step 2826). As discussed above, the Client Interface (via Resource 
Manager Module 206) allows an enterprise affiliate to identify a role or role profile that may be 
assigned to an activity of the workflow. A role profile includes a Rolename that represents a 
5 "capability" or "skill set," which is needed to perform a task of a plan created from the 
workflow, where the task corresponds to the activity of the workflow. For example, Fig. 35 
depicts a user interface 3500 displayed by the Client Interface to receive a role profile. In the 
implementation shown in Fig. 35, the Client Interface receives a Rolename 3502 (e.g., "Project 
Manager") for the role profile via the enterprise affiliate clicking on an "Add" button 3504 and 
10 then entering Rolename 3502 in a dialog box 3506 that is displayed by the Client Interface. In 
another implementation, the Client Interface may also receive as additional entries (not shown) 
to dialog box 3506 a skill and an associated skill level for Rolename 3502 as part of this role 
'2 profile. For example, the enterprise affiliate may indicate to the Client Interface via the 
2 additional entries to dialog box 3506 that the Rolename 3502 of "Project Manager" be 
£-5 associated with a skill entitled "Object-oriented software programming" and with a skill strength 
of "7" on a scale of 10. Assuming an enterprise affiliate is developing a workflow for producing 
a software development tool, the enterprise affiliate may assign to activities in the workflow the 
"Project Manager" role profile with this skill and skill level. Thus, when a plan is created from 
r: this workflow, a resource having the appropriate skill and skill level will automatically be 
20 assigned by the Client Interface to tasks corresponding to the activities with the "Project 
~2 Manager" role assignment. 

The tool 200 stores the role profiles in association with the selected workflow activity on 
WebDAV Storage 142. The tool 200 saves significant costs in developing multiple workflows 
by allowing the enterprise affiliate to store the role profiles in association with the selected 
25 workflow activity on WebDAV Storage 142 so that the role profiles may be available for the 
enterprise affiliate to assign to an activity of another workflow that is also related to the selected 
workflow activity. In one implementation, the Client Interface stores the role profiles in a single 
role definition file (not shown) on WebDAV Storage 142. In another implementation, the Client 
Interface stores the role profiles in separate files (not shown) on WebDAV Storage 142. Each 
30 separate file has a name that is the same as the received Rolename 3502. In this implementation, 
using known WebDAV protocol, the Client Interface defines an associated WebDAV property 
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having a common name, such as "role profile," so that the Client Interface may later retrieve the 
role profiles stored on WebDAV storage. 

The role profiles may also be stored with the workflow definition file. As shown in the 
workflow definition file 3300 depicted in Fig. 33, the role profile 3334 for the "Get Parts" 
5 activity 606 indicates that the role responsible for the activity is "Assembler" 3336. Similarly, 
the role profile 3338 for the "L or Rt Handed?" activity 608 indicates that the role responsible 
for the activity is "Assembler" 3340. The role profile 3342 for the "Right" activity 610 indicates 
that the role responsible for the activity is "Assembler" 3344. The role profile 3346 for the 
"Left" activity 612 indicates that the role responsible for the activity is "Assembler" 3348. The 
10 role profile 3350 for the "Left Special" activity 614 indicates that the role responsible for the 
activity is "Assembler" 3352. Finally, the role profile 3354 for the "Complete Assembly" 
activity 620 indicates that the role responsible for the activity is "Assembler" 3356. 

The next step performed by the tool 200 is to determine whether the activity has any 
I predecessor activities (step 2828). If the activity does have a predecessor activity, the tool 200 
15 receives an indication of the predecessor activities from the workflow definition file (step 2830). 
- After checking for any predecessor activities and/or receiving the predecessor activities, the tool 
T 200 determines whether the activity has any successor activities (step 2832). If the activity has a 
successor activity, the tool 200 receives an indication of the successor activities from the 
workflow definition file (step 2834). In the user interface 3400 of Fig. 34, the "Path" icon 3420 
10 is used to connect the predecessor activity to the successor activity. For example, in the 
* workflow 3402, a path 3422 was drawn from the "Assignment" activity 3404 to the "Analysis" 
activity 3406. Thus, the "Assignment" activity 3404 is the predecessor activity to the 
"Analysis" activity 3406, and the "Analysis" activity 3406 is the successor activity to the 
"Assignment" activity 3404. Alternatively, a "Vertical Fork/Join" icon 3424 or a "Horizontal 
25 Fork/Join" activity may be used to connect more than one predecessor activities to a successor 
activity, or to connect a predecessor activity to more than one successor activities. 

In the workflow 600 depicted in Fig. 6, the activity ID 3358 of the "Get Parts" activity 
606 is "10." The predecessor 3360 to the "Get Parts" activity 606 has an ID of "11" 3362, 
which corresponds to the start element 602. The successor 3364 to the "Get Parts" activity 606 
30 has an ID of "1522" 3366, which corresponds to the "L or Rt Handed?" logic activity 608. The 
predecessor 3368 to the "L or Rt Handed?" logic activity 608 has an ID of "10" 3358, which 
corresponds to the "Get Parts" activity 606. Because the "L or Rt Handed?" activity 608 is a 



logic activity, it has both a default successor and a non-default successor. Thus, the workflow 
definition file 3300 identifies two paths out of the "L or Rt Handed?" logic activity 608, one 
path 3370 has an ID of "1525" 3372, which corresponds to the "Right" activity 610, and the 
other path 3374 has an ID of "1523" 3376, which corresponds to the "Left" activity 612. The 
element representing the "L or Rt Handed? logic activity 608 also identifies that the default path 
3378 has an ID of "1525" 3372, which corresponds to the "Right" activity 610. The predecessor 
3380 to the "Right" activity 610 and the predecessor 3382 to the "Left" activity 612 have an ID 
of "1522" 3366, which corresponds to the "L or Rt Handed?" logic activity 608. The remaining 
predecessor and successors follow this convention. 

After checking for any successor activities and/or receiving the successor activities, the 
tool 200 determines whether the activity has any on-entry scripts (step 2836). An on-entry script 
is a step to be performed by the tool 200 upon entry into the activity. For example, the on-entry 
script may send an email notifying an interested user about the activity being started. The on- 
entry script may also send a dialog box to an enterprise affiliate to obtain data in real-time, or 
send a request to a separate device to gather input, e.g., by sending a message to a computer to 
receive data files. Other examples of on-entry scripts include checking stock levels and issuing 
reorder commands, if necessary, or paging the user assigned to perform the activity. If the 
activity has an on-entry script, the tool 200 receives an indication of the on-entry scripts (step 
2838). After checking for any on-entry scripts and/or receiving the on-entry scripts, the tool 200 
determines whether the activity has any on-exit scripts (step 2840 in Fig. 28C). An on-exit 
script is a step to be performed by the tool 200 upon exiting the activity. For example, the on- 
exit script may send an email notifying an interested user about the end of an activity. Other 
examples of on-exit scripts include sending a message to another device to have the other device 
perform enterprise application integration, notifying a downstream consumer about the activity 
so that the consumer knows what is coming, and placing an activity on a user's personal 
calendar. If the activity has an on-exit script, the tool 200 receives an indication of the on-exit 
scripts (step 2842). For example, the "Complete Assembly" activity 620 depicted in Fig. 6 
includes both an on-entry script 3384 as well as an on-exit script 3386. Upon entering the task 
created from the "Complete Assembly" activity, the tool 200 sends an email to the owner 
indicating that the "Debugging period started" 3388. Prior to exiting the task created from the 
"Complete Assembly" activity, the tool 200 sends an email to the owner indicating that the 
"Debugging finished" 3390. 
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After checking for any on-exit scripts and/or receiving the on-exit scripts, the tool 200 
determines whether the activity has any input (i.e., begin or starting) conditions (step 2844). If 
the activity has an input condition, the tool 200 receives an indication of the input conditions 
(step 2846). Example input conditions are to expect an artifact required for the task to have a 
specific status. After checking for any input conditions and/or receiving the input conditions, 
the tool 200 determines whether the activity has any output (i.e., exit or ending) conditions (step 
2848). An example exit condition could be to automatically check the quality of an artifact 
generated by the task. If the artifact meets quality standards, the task completion occurs; 
otherwise, the task completion is rejected and the user is informed that more quality is required. 
If the activity has an output condition, the tool 200 receives an indication of the output 
conditions (step 2850). The output condition 3391 for the "Get Parts" activity 606 has an ID of 
"1527" 3392 (Fig. 33B), and is a document-type condition, as indicated by the "linkablel" 
identity 3393 in the element 3394 representing the condition 3391. In general, based on the 
condition 3391, the tool 200 (in particular, the Workflow Engine 222) monitors the state of an 
artifact for an activated "Get Parts" task created from the "Get Parts" activity 606 until the state 
of the artifact is the "INITIAL" state 3395 before the tool 200 continues with the next task in the 
plan. Similarly, the output condition 3396 for the "Right" activity 610 has an ID of "1533" 
3397. The output condition 3396 for the "Right" activity 610 is also a document-type condition, 
as indicated by the "linkablel" identity 3398. This condition 3396 signals the tool 200 to 
monitor the state of an artifact until it is in the "RIGHT" state 3399. 

Fig. 36 depicts an exemplary user interface 3600 displayed by the Client Interface 134 to 
include either a document-oriented 3602 or a script (or logic)-oriented 3604 condition. As 
shown in Fig. 36, the Client Interface 134 may receive the request to add a condition to the 
activity via a pull-down menu selection 3606. The enterprise affiliate may, however, use any 
known data input technique to request that a condition be added to an activity, such as an icon or 
keyboard input, to indicate the request to the Client Interface 134. If the enterprise affiliate 
selects a document-oriented condition, the enterprise affiliate may be presented with the user 
interface 3700 depicted in Fig. 37 to identify the properties of the condition to the Client 
Interface 134. The condition properties 3702 include condition-name property 3704 for. the 
document-type condition model. In the example shown in Fig. 37, the Client Interface 134 
receives the condition-name property 3704 via a keyboard input by the enterprise affiliate. The 
Client Interface 134 uses the condition-name property 3704 to distinguish the condition model to 
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be created from other condition models stored on WebDAV Storage 142. The Client Interface 
134 may store the document-type condition model file on WebDAV Storage 142 having the 
same name as the condition-name property 3704. In another implementation, the Client 
Interface 134 may store the condition-name property 3704 as a WebDAV property stored in 
5 association with the document-type condition model file on WebDAV Storage 142. 

The Client Interface 134 also receives a link-parameter property 3706 as one of 
Condition properties 3702 for the document-type condition model to be created by the Client 
Interface. As shown in Fig. 37, the enterprise affiliate may identify link-parameter property 
3706 to the Client Interface via keyboard input. Link-parameter property 3706 may be used by 

10 an enterprise affiliate in an activity-related script that is identified to the Client Interface during 
the creation of a workflow as described below. Thus, when executing the activity-related script 
in a task of a plan created from the workflow, the Workflow Engine 222 in Fig. 2 is able to 

-2 locate the corresponding document condition so that the corresponding input or output condition 
may be evaluated by the Workflow Engine 222. 

15 The Client Interface 134 may also receive a description property 3708 as one of 

Condition properties 3702 for the document-type condition model to be created by the Client 
Interface. When creating a workflow as described below, the Client Interface may display 
description property 3708 in association with condition-name property 3704 to allow an 

, z enterprise affiliate to effectively choose whether the document-type condition model should be 

,20 assigned to an activity of the workflow. 

~ The Client Interface may also receive one or more triggering-event properties 3710 for 

the document-type condition model. In the example shown in Fig. 37, the Client Interface may 
receive the triggering-event properties as one of the condition properties 3702 for the document- 
type condition model to be created by the Client Interface. Triggering-event properties 3710 

25 indicate to the Workflow Engine 222 when to check the state property of a document condition 
as an entry or exit condition of an activated task. Triggering-event properties 3710 may include 
a "Write into document" event 3712, a "Change property of document" event 3714, a "Put 
document into repository" event 3716, a "copy or move into document" event 3718, and a 
"delete document" event 3720. 

30 Next, the Client Interface 134 receives document state properties 3722 as one of the 

Condition properties 3702 for the document-type condition model to be created by the Client 
Interface. Document state properties 3722 identify possible values for a state property of a 



document condition that is created using the document-type condition model. As further 
explained herein, an enterprise affiliate who has been identified as the responsible owner of an 
activated task may change the state property of a document condition (e.g., from "DRAFT" to 
"APPROVED") using the Client Interface, which sends a request to WebDAV Server 140 in 
5 Fig. 2 to set the state property of the document condition as indicated by the enterprise affiliate. 
Workflow Engine 222 in Fig. 2 may then check the state property of the document condition on 
WebDAV Storage 142 when triggering-events 3710 occur. 

The Client Interface also receives a location property 3724 as one of Condition 
properties 3702 identified by the enterprise affiliate for the document-type condition model. 
10 Location property 3724 is a unique identifier or URL for a document template that the Client 
Interface uses to create the document condition that is then stored by the Client Interface on 
WebDAV Storage 142. Location property 3724 may be a location on secondary storage device 
« 116 of computer 102a or a location on WebDAV Storage 142. As described in greater detail 
£ below, the document condition is created by the Client Interface 134 when a plan is instantiated 
13 or created from a workflow having an activity with an entry or exit condition created using the 
'2 document-type condition model. Finally, the Client Interface receives application property 3726 
Z as one of Condition properties 3702 identified by the enterprise affiliate for the document-type 
~_ condition model. Application property 3726 is a unique identifier or URL for an application, 
-I such as Microsoft Word, that the Client Interface may run to create an instant of the document 
40 template that may be found at the location specified by location property 3724. The Client 
Interface uses the instant of the document template to create and store the document condition 
on WebDAV Storage 142. 

Fig. 38 depicts an exemplary user interface 3800 displayed by the Client Interface 134 to 
receive the condition properties 3802 for a logic-type condition model that is to be created by the 
25 Client Interface 134. The condition properties 3802 include a condition-name property 3804 for 
the document-type condition model. In the example shown in Fig. 38, the Client Interface 134 
receives the condition-name property 3804 via a keyboard input by the enterprise affiliate. The 
Client Interface 134 uses the condition-name property 3804 to distinguish the logic-type 
condition model to be created from other condition models stored on WebDAV Storage 142. As 
30 described below, the Client Interface 134 stores a logic-type condition model file on WebDAV 
Storage 142 that has the same name as condition-name property 3804. In another 
implementation, the Client Interface 134 may also store condition-name property 3804 as a 



WebDAV property stored in association with the logic-type condition model file on WebDAV 
Storage 142. 

In the example shown in Fig. 38, the Client Interface 134 may receive a description 
property 3806 as one of the Condition properties 3802 for the logic-type condition model to be 
5 created by the Client Interface 134. When creating a workflow as described below, the Client 
Interface 134 may display the description property 3806 in association with the condition-name 
property 3804 to allow an enterprise affiliate to effectively choose whether the logic-type 
condition model should be assigned to an activity of the workflow. 

The Client Interface 134 may also receive one or more triggering-event properties 3808 

10 for the logic-type condition model as one of the condition properties 3802 for the logic-type 
condition model to be created by the Client Interface 134. Triggering-event properties 3808 
indicate to the Workflow Engine 222 when to check an entry or exit condition of an activated 

O task. Triggering-event properties 3808 include: an "Absolute time" event 3810, a "Period" 
5 event 3812, a "URL change" event 3814, a "Task change" event 3816, and "any http request" 
!|5 event 3818. "Absolute time" event 3810 identifies a trigger for a specific data and time from the 
D start time of the activated task. "Period" event 3812 identifies a trigger for a specific unit of 

11 time, such as once every minute. "URL change" event 3814 identifies a trigger when the 
JL, contents of the directory or folder located at the URL changes. "Task change" event 3816 
ffl identifies a trigger for any time the activated task definition file or associated property changes. 
2J) For example, when an enterprise affiliate that is responsible for the task uses the Client Interface 
M 134 to identify that the task is complete, the Client Interface 134 in response sends a request to 

the WebDAV Server 140 to set the status property of the activated task to "FINISHED." As 
part of the processing for managing an activated plan as described below, the Workflow Engine 
222 will receive this request before the WebDAV Server 140 and interpret the request as an 

25 example of a "Task change" event 3816. Similarly, "Any http request" event 3818 indicates to 
the Workflow Engine 222 to check the entry or exit condition of the activated task when any 
request is received from the Client Interface 134 that pertains to the activated task. For example, 
the Client Interface 134 may send a request to the WebDAV Server 140 to retrieve the activated 
task file so that a status of the activated task can be viewed by an enterprise affiliate. Workflow 

30 Engine 222 will receive this request before the WebDAV Server 140 and interpret the request as 
an example of an "Any http request" event 3818. 
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The Client Interface 134 may also receive a script 3820 as one of the condition properties 
3802 for the logic-type condition model to be created by the Client Interface 134. Script 3820 is 
executed by the Workflow Engine 222 when a triggering-event occurs that corresponds to one of 
the triggering-event properties 3808 selected by the enterprise user using the Client Interface 
5 134. As shown in Fig. 38, Script 3820 may include a script parameter 3822, a script value 3824 
for script parameter 3822, and script content 3826 that may use the script parameter 3822 
initialized to the script value 3824. The enterprise affiliate may provide the script content 3826 
to the Client Interface 134 via a Script Editor User Interface 3900 in Fig. 39. Script Editor User 
Interface 3900 is displayed by the Client Interface 134 when the enterprise affiliate actuates 
10 button 3828 on user interface 3800 shown in Fig. 38. Script content 3820 may contain any 
known application program interface (API) script method that would be recognizable by the 
target processor interpreter on computer 106, such as Java™ Virtual Machine 1 50 in Fig. 1 . 
Q After checking for any output conditions and/or receiving the output conditions, the tool 

5 200 determines whether there are any more activities to add to the workflow (step 2852). If 
fe there are more activities, the process continues at step 2822 for the next activity. If there are no 
O more activities to add to the workflow, the tool 200 receives an indication of the starting point 
%1 for the workflow (step 2854). Next, the tool 200 receives an indication of the ending point for 
JL the workflow (step 2856) before the process ends. 

ID Fig. 40 depicts an exemplary user interface 4000 displayed by the Client Interface 134 to 

8p receive the properties of an activity of a workflow. As depicted, the name 4002 of the activity 
p (e.g., "Specs Development"), the duration 4004 of the activity (e.g., 1 unit) and the role 4006 
responsible for the activity may be entered by the enterprise affiliate responsible for creating or 
modifying the workflow. In addition, the enterprise affiliate may enter an on-entry script 4008 
as well as an on-exit script 4010. If the activity represents an .entire other workflow, the 
25 properties of the activity also include the location 4012 of the sub-process defining the 
workflow. This allows an enterprise to save significant resources by providing a mechanism for 
reusing workflows within other workflows. Thus, workflows may be modularly built from 
constituent workflows. For example, the defect tracking workflow depicted in Fig. 34 can be 
used inside many "outer" or "higher-level" processes for software development. 

30 Creating A Plan From A Workflow 
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Figs. 41A-B depict a flow diagram illustrating the process of creating a plan from a 
workflow, i.e., step 306 in Fig. 3. At this point, the enterprise affiliate has already selected the 
workflow that will be used to create the plan. Initially, the tool 200 receives an indication of the 
plan name (step 4102). In selecting the plan name, the Client Interface 134 allows the enterprise 
5 affiliate to store the project plan within an identified project plan group so that any enterprise 
affiliate using the Client Interface 134 is able to easily identify related project plans. A process 
plan group is a collection of project plans (e.g., a directory or folder containing the collection of 
project plans) created by the Client Interface 134 on WebDAV Storage 142. For example, the 
software-related project plans may be stored within the same project plan group so that an 
10 enterprise affiliate is able to quickly locate a desired project plan in order to create a 
corresponding plan using the Client Interface 134. One skilled in the art will appreciate that 
Client Interface 134 may store a project plan on WebDAV Storage 142 without associating the 
project plan with a project plan group. Fig. 42 depicts an exemplary user interface 4200 used to 

- receive a proj ect plan group. 

±5 In the implementation shown in Fig. 42, the Client Interface 134 receives a dialog box 

4202 to enter the name of a new project plan group 4204 (e.g., "Software Projects") after 
clicking on a "Create Group" button 4206. Alternatively, if the enterprise affiliate decides to 
select an existing project plan group, the tool 200 provides the enterprise affiliate with a list 
" 4300 of available project groups from which the enterprise affiliate may choose, as depicted in 
20 Fig. 43. The tool 200 then provides the enterprise affiliate with a dialog box 4400 to enter the 

- name 4402 of the project, as shown in Fig. 44. 

The next step performed by the tool 200 is to receive an indication of the working hours 
(step 4104). Fig. 45 depicts an exemplary timetable 4500 which the enterprise affiliate may use 
to identify the timetable defining a workday. As shown, the enterprise affiliate may select a 

25 timetable template 4502 with predefined working hours. The Standard Timetable 4504 includes 
five Working Days 4506 (Monday through Friday) and Working Hours 4508 from 8 a.m. (4510) 
through 12 p.m. (4512) and from 1 p.m. (4514) until 5 p.m. (4516). Alternatively, the enterprise 
affiliate may select a 24 Hour Timetable 4518 or an Intensive Timetable 4520, i.e., more than 
the Standard Timetable 4504, but less than the 24 Hour Timetable 4518. The tool 200 also 

30 receives an indication of the start date and time for the project plan (step 4106). An exemplary 
dialog box 4600 may be used to select the start date and time 4602 and end date and time 4604. 
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The tool 200 then retrieves an activity from the workflow (step 4108). The tool 200 sets 
the start time of the task equal to the start date and time of the project plan (step 4110). Next, 
the tool 200 sets the end time of the task based on the start time of the task, the duration of the 
activity from which the task is based, and on the working hours (step 4112 in Fig. 41B). The 
5 tool 200 then receives an indication of the resource assigned to the task (step 4114). 

For example, Fig. 47 depicts an exemplary workflow definition file 4700 that is 
produced by the tool 200 when the workflow 500 depicted in Fig. 5 is created. Fig. 48 depicts 
an exemplary project plan definition file 4800 created from the workflow definition file 4700. 
The element 4702 in the workflow definition file 4700 represents the "Serial 1" activity 506. As 
10 shown, the "Serial 1" activity 506 has a duration 4704 of 9 hours. If the working hours are 
determined based on the "24 Hour Timetable" 4818 and the start date and time for the project 
plan is 9 a.m. on August 1, 2001, the start time 4804 for the "Serial 1" task 4802 is 9 a.m. on 
q August 1, 2001. The end time 4806 of the task 4802 occurs 9 hours later, i.e., at 6 p.m. on 
'% August 1,2001. 

t5 Fig. 49 depicts an exemplary user interface 4900 displayed by the Client Interface 134 to 

Q assign users or resources to the project and to assign these users specific roles related to the roles 
'[\ required by the project. The tool 200 displays a list of available users or resources 4902 (on the 
*L left), a list of the assigned users (central), and a list of the roles 4904 (on the right) in a given 
:Ji workflow. In this embodiment, the enterprise affiliate is allowed to selectively add or remove 
"20 available resources to the project by highlighting the resource and selecting either the "Add" 
=iS button 4906 or the "Remove" button 4908, respectively. Alternatively, the enterprise affiliate 
may add or remove the resources to the project by selecting the "Add all" button 4910 or the 
"Remove all" 4912 button, respectively. For each resource, the user can selectively indicate 
(checkboxes) which roles the user should play. Thus, the enterprise affiliate may identify to the 
25 tool 200 resources that are capable of performing the role when assigned to a task in the plan. 
As discussed below, the tool 200 may automatically assign a resource to a role of a task in the 
plan based on the identified, capable resources for the role. 

The properties of an activity may be modified using the exemplary user interface 5000 
depicted in Fig. 50. The user interface 5000 displays the name 5002 of the activity, the duration 
30 5004 assigned to the corresponding activity, the start date and time 5006 for the activity, the end 
date and time 5008 for the activity, the responsible role 5010 assigned to the corresponding 
activity, the responsible resource or user 5012 assigned to the task, the owners 5014 of the task, 



the priority 5016 of the task, the on-entry script 5018 of the task, and the on-exit script 5020 of 
the task. The responsible resource 5012 of the task is the resource with the authority to notify 
the tool 200 when the task is complete. The owner(s) 5014 of the task, on the other hand, are 
notified when the task is started or completed, but do not have the authority to modify the tool 
5 200 when the task is complete. 

The next step performed by the tool 200 is to determine whether there are any more 
activities in the workflow (step 41 16). If there are no more activities, the process ends. If there 
are more activities, the tool 200 retrieves the next activity (step 4118). The tool 200 then sets 
the start time of the task equal to the end time of the predecessor task (step 4120). The process 
1 0 then continues at step 4112. 

The next activities that are retrieved by the tool 200 are "Parallel 1" 510 and "Parallel 2" 
512. Element 4706 and element 4708 in the workflow definition file 4700 represent these 
O activities 510 and 512. The durations 4710 and 4712 of both of these activities is 24 hours. The 
3 start time 4812 and 4814 of these tasks 4808 and 4810 is equal to the end time 4806 of the 
jfe predecessor task, i.e., 6 p.m. on August 1, 2001. Because the duration 4710 and 4712 of the 
O activities 510 and 512 is 24 hours, the end times 4816 and 4818 of these tasks 4808 and 4810 
fH occur 24 hours later, i.e., at 6 p.m. on August 2, 2001. The next activity retrieved by the tool 
1_ 200 is "Serial 2" 508. The element 4714 in the workflow definition file 4700 represents this 
IB activity. The duration 4716 of the "Serial 2" activity 508 is 24 hours. The start time 4822 of the 
lip task 4820 created from the "Serial 2" activity 508 is the end time 4816 and 4818 of the 
p predecessor task, i.e., 6 p.m. on August 2, 2001. Because the duration 4716 of the "Serial 1" 
activity is 24 hours, the end time 4824 of the task 4820 is 6 p.m. on August 3, 2001 . The project 
plan is displayed in the Gantt chart 5100 depicted in Fig. 51. As shown, the "Serial 1" task 5102 
is scheduled to execute from 9 a.m. 5104 on August 1, 2001 (5106) through 6 p.m. 5108 on the 
25 same day. The "Parallel 1" task 5110 and the "Parallel 2" task 5112 are scheduled to execute 
from 6 p.m. 5108 on August 1, 2001 (5106) through 6 p.m. 5114 on August 2, 2001 (5116). 
Finally, the "Serial 1" task 5118 is scheduled to execute from 6 p.m. 5114 on August 2, 2001 
(5116) through 6 p.m. 5120 on August 3, 2001 (5122). Note that an enterprise affiliate using the 
Client Interface 134 on the computer 102a may create a plan from the workflow 600 at the same 
30 time that a second enterprise affiliate using the Client Interface 134 on computer 102n creates a 
second plan from the workflow 600. 
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After the project plan is created from the workflow, the plan may be activated. As 
depicted in Fig. 52, the enterprise affiliate may activate the project by selecting the "Activate 
Project" option 5202 from the pull-down menu 5200. The enterprise affiliate may, however, use 
any known data input technique, such as an icon or keyboard input, to indicate the request to 
5 Client Interface 134. 

In one implementation, the Client Interface 134 then sends an activate request to the 
WebDAV server 140 to change the status of the plan definition file to "Active." As discussed 
further below, the Workflow Engine 222 may intercept this request and process the request in 
preparation for managing the execution of the activated plan. Once the plan is created and 
10 stored on WebDAV storage 142, any enterprise affiliate with appropriate privileges (e.g., project 
manager that "owns" the plan) may activate the plan using the Client Interface 134 from any 
computer 102a and 102n. 

Z Adding A Resource 

Fig. 53 depicts a flow diagram illustrating an exemplary process performed by the Client 

t5 Interface 134 to add a new resource to the list of available resources. The Client Interface 134 
may later assign the resource to a plan in accordance with methods and systems consistent with 
the present invention. Initially, the Client Interface 134 receives a request to add a new resource 
(step 5302). As shown in Fig. 54, the Client Interface 134 may receive the request to add a new 

~= resource via a pull-down menu selection 5402 and 5404 that is chosen by an enterprise affiliate. 

20 The enterprise affiliate may, however, use any known data input technique, such as an icon or 
keyboard input, to indicate the request to the Client Interface 134. 

Next, the Client Interface 134 determines whether the request is to import the resource 
information (step 5304). In the implementation shown in Fig. 54, an enterprise affiliate requests 
that the Client Interface 134 import a resource profile containing the resource information by 

25 choosing the pull-down menu selection 5404. Alternatively, the enterprise affiliate may request 
that the Client Interface 134 create the resource profile from resource information that the 
enterprise affiliate provides to the Client Interface 134. Thus, if the request is not to import the 
resource information, the Client Interface 134 receives the resource information from the 
enterprise affiliate (step 5306). As shown in Fig. 54, the Client Interface 134 may receive 

30 resource information 5404 for an enterprise affiliate (e.g., a user or person) that may later be 
assigned to a plan by the Client Interface 134 in accordance with processes described in greater 
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detail below. The Resource Information 5404 may include a login name 5408, a resource name 
5410 that the Client Interface 134 is to use when assigning the resource to a task of a plan, and 
an e-mail address 5412 that the Client Interface 134 or the Workflow Engine 222 may use to 
notify the resource of an assignment or another event. 
5 The Client Interface 134 may also receive other resource information (not shown) for 

other types of resources (e.g., equipment, facilities, computer systems, or other known entities) 
that may be assigned to any task of a plan. The other resource information may include: a 
resource name that the Client Interface 134 is to use when assigning the resource to a task of a 
plan; a resource owner name that identifies a manager or other enterprise affiliate who is 
1 0 responsible for the named resource; and an e-mail address for the named resource owner, which 
the Client Interface 134 or the Workflow Engine 222 may notify when the named resource is 
assigned to a task or for another associated event. 
I~ Resource information 5404 may also include one or more skill identifiers that indicate 

one or more capabilities that a task of a plan may require for the task to be completed. Skill 
15 identifiers may include any foreseeable skill for the named resource, including a user, 
~ equipment, facilities, computer systems, or other known entities that may be assigned to any task 
of a plan. For example, when the named resource is an enterprise affiliate, the skill identifiers 
that may be identified for the enterprise affiliate may include: "Java programming," 
z. "architecture," or "carpentry." When the named resource is equipment, the skill identifiers may 
20 include "punch-press," "printing," or "Windows NT Operating System." Or, when the resource 
~ is another system, skills may involve the ability to execute specific functions (much like 
distributed or web services, "credit card validation," "shop for best air freight shipper prices"). 
Resource information 5404 may also include a skill strength (not shown) for each skill identifier. 
The skill strength may be used by the tool to differentiate one resource from another resource 
25 when matching a resource to a role of a task in a plan. 

Resource information 5404 may also include an availability timetable (not shown) that 
indicates to the Client Interface 134 the calendar days, the hours in a weekday, and the hours in a 
weekend day that the named resource is available to work. Resource information 5404 may also 
include an assignment timetable (not shown) that has assigned calendar days. The assigned 
30 calendar days indicate to the Client Interface 134 which calendar days the named resource has 
been assigned to one or more tasks. In addition, the assignment timetable may include unique 
identifiers or URLs for the one or more tasks to which the named resource has been assigned. 
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Thus, the Client Interface 134 or the Workflow Engine 222 may access the one or more tasks 
that the named resource has been assigned when performing processing for resource leveling of 
a plan in accordance with methods and systems consistent with the present invention. 

If the request is to import the resource information, the Client Interface 134 receives 
5 access information for a "Lightweight Directory Access Protocol (LDAP)" resource directory 
entry (e.g., a resource profile) on the network 108 of Fig. 1 (step 5308). Fig. 55 depicts an 
exemplary user interface 5500 showing access information 5502 received by the Client Interface 
134. Access information 5502 includes an LDAP Server 5504 (e.g., "Frodo") on the network 
108, an LDAP Port 5506 for the Client Interface 134 to communicate with the LDAP Server 
10 5504, and a resource distinguished name (DN) 5508 identifying the location on LDAP Server 
5504 where the resource profile may be found. The access information 5502 may be default 
access information that the Client Interface 134 retrieves from a configuration file (not shown) 
on the computer 102a, or it may be access information entered by an enterprise affiliate. In the 
: implementation illustrated in Fig. 55, the access information 5502 may also include: a security 
IS distinguished name (DN) 5510, a password 5512, and a login alias 5514. Security DN 5510 
2 identifies to the Client Interface 134 where a security profile for the enterprise affiliate is 
located. The Client Interface 134 uses the password 5512 and the login alias 5514 to access the 
resource information on the LDAP Server 5504 in accordance with privileges identified in the 
™ security profile. 

JO Having received the access information for the LDAP directory entry on network 108, 

the Client Interface 134 retrieves the resource information using the LDAP access information 
(step 5310). The resource information that the Client Interface 134 retrieves includes resource 
profiles for a user, equipment, facilities, computer systems, or other known entities that may be 
assigned to any task of a plan. 

25 After the resource information is received from the enterprise affiliate or is retrieved 

using LDAP access information, the Client Interface 134 stores the resource information in 
resource profiles on the WebDAV Storage 142 (step 5312). 

Fig. 56 depicts an exemplary resource file 5600 that the Client Interface 134 may use to 
store resource profiles 5602, 5604, 5606, and 5608 on WebDAV Storage 142. As shown in Fig. 

30 56, the resource profile 5600 includes a unique identifier or URL 5612 where the resource 
profile 5600 is to be stored on the WebDAV Storage 142. Each resource profile 5602, 5604, 
5606, and 5608 may be stored separately by the Client Interface 134 on WebDAV Storage 142. 



In the implementation shown in Fig. 56, the resource profile 5602 includes resource information 
5610 that corresponds to an enterprise affiliate that may be assigned to a task of a plan. In 
another implementation, the resource information 5610 may be added as properties rather than 
as the content of the resource profile 5602 on WebDAV Storage 142. This implementation may 
5 be advantageous as the Client Interface 134 or the Workflow Engine 222 may use a known 
WebDAV method to retrieve resource profiles from the WebDAV Storage 142 that have the 
same property. For example, the WebDAV "PropFind" method may be used by the Client 
Interface 134 or the Workflow Engine 222 to retrieve the resource profiles having a skill 
identifier of "Java Programming" so that an available resource having this skill can be assigned 
10 to a task in accordance with processes described below. 

Managing A Plan 

5 Fig. 57 depicts a flow diagram illustrating an exemplary process performed by the 

CI Workflow Engine 222 to manage the execution of an activated plan. The Workflow Engine 222 
m may execute the process in Fig. 57 for each activated plan stored on WebDAV Storage 142. 
U Thus, the tool manages the execution of multiple plans simultaneously. 

H Initially, the tool 200 waits until the current time and date are later than the start time and 

date (step 5702) of the plan. Alternatively, a plan may not require a start time and date for each 
SB plan. Rather, the start time and date may be incorporated as an input condition for each task. At 
yL this point, the tool 200 selects the current next task (or tasks in the event of parallel tasks) from 
^3 the activated project plan created from a workflow (step 5704). Note that the Workflow Engine 
222 may retrieve the plan from WebDAV storage. Next, the tool 200 determines whether there 
is an input condition (step 5706). If there is an input condition, the tool 200 waits to see if the 
triggering event (described above) is met before it checks to see if the input condition is met 
(step 5708). If the input condition required monitoring of certain items on a periodic basis, the 
25 Workflow Engine 222 will add this event to its "Event Monitoring" log. After the input 
condition is met or if there is no input condition, the tool 200 stores the actual start time (step 
5710). The next step performed by the tool 200 is to determine whether there is an on-entry 
script to execute, such as a message to send to the resource (step 5712 in Fig. 57B). If there is 
an on-entry script, the tool 200 performs the on-entry script (step 5714). After performing the 
30 on-entry script or if there is no on-entry script, the tool 200 determines whether there is an 
output condition (step 5716). If there is an output condition, the tool 200 waits to see if the 



triggering event (described above) is met before it checks to see if the output condition is met 
(step 5718). After the output condition is met or if there is no output condition, the tool 200 
determines whether there is an on-exit script (step 5720). If there is an on-exit script, the tool 
200 performs the on-exit script (step 5722). After performing the on-exit script or if there is no 
5 on-exit script, the tool 200 stores the actual end time (step 5724). Then the tool 200 determines 
whether there are any more tasks in the project plan (step 5726). If there are no more tasks, the 
process ends. Otherwise, the process returns to step 5704 and selects the next task. 

The plan 5800 created from the workflow 500 depicted in Fig. 5 is shown in Fig. 58. As 
shown in Fig. 58, "Serial 1" task 5802 is scheduled to begin at 9 a.m. 5804 on August 1, 2001 
10 (5806) and end at 6 p.m. 5808 on the same day. The parallel tasks 5810 and 5812 are scheduled 
to start at the completion of the "Serial 1" task 5808, and are scheduled to end at 6 p.m. 5814 on 
August 2, 2001 (5816). The "Serial 2" task 5818 is scheduled to begin upon completion of the 
:.: parallel tasks 5814 and is scheduled to end at 6 p.m. 5820 on August 3, 2001 (58-22). Fig. 59 
'~\ depicts an exemplary project plan definition file 5900 corresponding to the plan 5800 of Fig. 58. 
-f;5 Upon activation, the "Serial 1" task 6002 begins execution, as depicted by the task 6004 

2 in the Gantt chart 6000 of Fig. 60. Contrary to the plan, however, the "Serial 1" task ends earlier 
{2 than planned. As depicted in Fig. 61, the actual properties 6100 of the "Serial 1" task 6102 
include the actual-start-date 6104 (i.e., year-2001 month-8 day-1 hour-9) and actual-finish-date 
/r 6106 (i.e., year-2001 month-8 day-1 hour-14, i.e., 2 p.m.). The actual execution 6204 of the 
2p "Serial 1" task 6202 is shown in the Gantt chart 6200 of Fig. 62. 

Z Because the "Serial 1" task 6202 ended earlier than planned, both the "Parallel 1" task 

6206 and the "Parallel 2" task 6208 begin execution at 2 p.m. 6210 rather than waiting until their 
scheduled start time of 6 p.m. The earlier execution 6212 and 6214 of these tasks 6206 and 
6208 is also depicted in the Gantt chart 6200. As depicted in Fig. 63, the actual properties 6300 

25 of the "Parallel 1" task 6302 and the "Parallel 2" task 6304 include the actual-start-date 6306 
(i.e., year-2001 month-8 day-1 hour-14) and actual-fmish-date 6308 (i.e., year-2001 month-8 
day-2 hour-0). The actual execution 6406 and 6408 of the "Parallel 1" task 6402 and the 
"Parallel 2" task 6404 is shown in the Gantt chart 6400 of Fig. 64. The Gantt chart 6400 also 
visually indicates that the start time 6410 for the tasks 6402 and 6404 was 2 p.m. on August 1, 

30 2001, while the end time 6412 for the tasks 6402 and 6404 was 12 a.m. on August 2, 2001. 

Finally, the execution of the "Serial 2" task 6414 begins at 12 a.m. on August 2, 2001 
(6412). As depicted in Fig. 65, the actual properties 6500 of the "Serial 2" task 6502 includes 



the actual-start-date 6504 (i.e., year-2001 month-8 day-2 hour-0) and actual-finish-date 6506 
(i.e., year-2001 month-8 day-2 hour-12). The actual execution 6604 of the "Serial 1" task 6602, 
the actual execution 6608 of the "Parallel 1" task 6606, the actual execution 6612 of the 
"Parallel 2" task 6610, and the actual execution 6616 of the "Serial 2" task 6614, are shown in 
5 the Gantt chart 6600 of Fig. 66. 

Improving A Workflow Based On Data Mined From Plans Created From The Workflow 

In addition to the functionality described above, the Client Interface 134 saves significant 
costs for an enterprise and increases the operating efficiency of the enterprise by optimizing a 
workflow using data mined from plans created from the workflow. The term "data mining" 

10 describes techniques for analyzing large amounts of enterprise data to determine trends, 
statistically significant information and functional relationships. The data mined by the Client 
Interface 134 may include planned duration and actual duration for a task of each plan created 

r from an activity of the workflow, where the actual duration is substantially different from the 

% planned duration (e.g., the task takes substantially longer or shorter to complete than planned) 

15 that was specified as a characteristic of the activity of the workflow. In this implementation, the 
Client Interface 134 may optimize the workflow by adjusting the planned duration of the activity 
in the workflow so that when another plan is subsequently created from the optimized workflow 
the task corresponding to the activity is created with an optimal duration based on the data 
mining results. In another implementation, the data mined by the Client Interface 134 may 

;2D include a resource assigned to the task. When creating a plan from a workflow, the planned (or 
automatically assigned) resource may be manually overridden with a replacement by an 
enterprise affiliate using the Client Interface 134. In this implementation, the Client Interface 
134 may optimize" the workflow by changing the role of an activity associated with the task to a 
new role based on the replacement resource or by changing a skill level of the responsible role 

25 of the workflow activity based on a different skill level of the replacement resource as found 
through the data mining of the plans. In another implementation, the data mined by the Client 
Interface 134 may include a successor of a task (i.e., the next task in the plan). The planned 
successor created by the Client Interface 134 from the workflow may be manually replaced by 
an enterprise affiliate with a non-default task (e.g., the other path of a logic activity) or by 

30 another default task (e.g., a replacement task that may be new to the plan or another task that 
occurs in the plan). While methods and systems consistent with the present invention describe 
the optimization of the duration, role, and successor of the activity in the workflow, it will be 



apparent to one of ordinary skill in the art that the Client Interface 134 may optimize the 
workflow based on differences of other characteristics between the plan and the workflow. 

Figs. 67A-D depict a flow diagram illustrating an exemplary process performed by the 
Client Interface 134 to improve a workflow that has been produced by the Client Interface 134 
5 when performing the process depicted in Fig. 3 as discussed above. Initially, the Client 
Interface 134 receives a request to optimize a workflow (step 6702). In one implementation, the 
Client Interface 134 first receives an indication that a workflow is to be optimized when an 
enterprise affiliate clicks a mouse on an optimization button of a user interface (not shown) 
displayed by the Client Interface 134. In this implementation, the Client Interface 134 responds 

10 by retrieving and displaying the identifications of all the workflow definition files stored on 
WebDAV Storage 142 of Fig. 2. The enterprise affiliate may then complete the request by 
identifying one of the displayed workflow definition files to the Client Interface 134 by clicking 
the mouse on the displayed identification corresponding to the workflow definition file. One 

= skilled in the art will appreciate that any known programming technique for inputting data may 

T5 be used to convey the same information to the Client Interface 134. 

Z In another implementation, the Client Interface 134 allows the enterprise affiliate to set a 

pre-defined threshold (not shown) for before commencing optimization of the workflow. For 
example, the enterprise affiliate may identify that after every 10 th use of the workflow to create a 
~Z project the Client Interface 134 is to perform methods consistent with the present invention to 
Z0 optimize the workflow or any workflow stored on WebDAV Storage 142. In another 
- implementation, the enterprise affiliate may identify plans to the Client Interface 134 that 
correspond to the workflow to be optimized by the Client Interface 134 using methods and 
systems consistent with the present invention. In general, the Client Interface 134 may retrieve 
the plans to examine or may monitor the plans as they are executed to identify characteristics of 
25 the plans that may be used to optimize the workflow as discussed below. For clarification in the 
discussion to follow, when performing step 6702 of Fig. 67A, it is assumed that the Client 
Interface 134 receives from the enterprise affiliate the request to optimize the workflow 
identified as "AssemblyWorkflow." 

After receiving the request to optimize the workflow, the Client Interface 134 retrieves a 
30 definition file for the workflow from WebDAV Storage 142 (Step 6703). Fig. 68 depicts an 
exemplary workflow definition file 6800 named "AssemblyWorkflow" that was produced by the 
Client Interface 134 after performing the process depicted in Fig. 3 and that is retrieved by the 
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Client Interface 134 in response to the request to optimize the workflow. Fig. 69 depicts an 
exemplary graphical representation 6902 of the workflow that is displayed by the Client 
Interface 134 after parsing the workflow definition file 6800 in Fig. 68 and before optimization 
processing is performed by the Client Interface 134. As shown in Fig. 68, workflow definition 
5 file 6800 for "AssemblyWorkflow" includes a "Get Parts" activity (6801 in Fig. 68 and 
graphically depicted as 6904 in Fig. 69), a "L Or Rt Handed?" logic activity (6828 and 6906), a 
"Right" activity (6842 and 6908), a "Left" activity (6846 and 6910), a "Left Special" activity 
(6850 and 6912), and a "Complete Assembly" activity (6854 and 6914). As shown in Fig. 69, 
"L Or Rt Handed?" logic activity 6906 has two outgoing paths, a default-path 6916 that is 
10 graphically depicted as a solid line and a non-default-path 6918 that is graphically depicted as a 
dashed line. Both "Get Parts" activity 6904 and "Complete Assembly" activity 6914 have one 
outgoing path or default path. Thus, in the example as shown in Fig. 69, the default-path for 
z: "AssemblyWorkflow" includes "Get Parts" activity 6904, "L Or Rt Handed?" logic activity 
- 6906, "Right" activity 6908, and "Complete Assembly" activity 6914. As discussed above, 
1=5 when the Client Interface 134 creates a plan from workflow definition file 6800, the Client 
Interface 134 creates tasks for the plan from activities in the default-path for 
"AssemblyWorkflow." As discussed below when performing optimization processing for 
^ "AssemblyWorkflow," an enterprise affiliate may request that the Client Interface 134 identify 
* plans created from the workflow definition file 6800 where the enterprise affiliate has manually 
20 changed each plan to reflect the non-default-path for "AssemblyWorkflow." 
7 After receiving the request to optimize the workflow, the Client Interface 134 receives 

one or more optimization conditions-to-check in a task of a plan created from an activity of the 
workflow (Step 6704). An optimization condition-to-check indicates to the Client Interface 134 
which planned- task-property and actual-task-property that the Client Interface 134 is to retrieve 
25 (or mine) and then evaluate to determine if the condition-to-check has been met or is true for a 
task created from an activity of the workflow. In general, the Client Interface 134 is able to 
perform the conditions-to-check on each task of each plan created from the activity in the 
workflow and then generate optimization suggestions for the activity that an enterprise affiliate 
may selectively choose to have the Client Interface 134 implement. 
30 Fig. 70 depicts an exemplary user interface 7000 displayed by the Client Interface 134 

for receiving the one or more conditions-to-check (i.e., 7002, 7004, and 7006) for "Get Parts" 
activity (6801 of Fig. 68 and graphically depicted as 6904 in Fig. 69) of the workflow. As 
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shown in Fig. 70, the one or more conditions-to-check that the Client Interface 134 may receive 
and process includes a duration-tolerance-exceeded condition 7002. When processing duration- 
tolerance-exceeded condition 7002, the Client Interface 134 determines if a planned-duration 
7008 plus a planned-duration-tolerance 7010 for a task has been exceeded. Planned-duration 
5 7008 corresponds to a duration-property (6802 in Fig. 68 and 7012 in Fig. 70) for the activity 
from which the task was created. Planned-duration-tolerance 7010 corresponds to a duration- 
tolerance-property (6804 in Fig. 68 and 7014 in Fig. 70) for the activity. In general, the Client 
Interface 134 allows an enterprise affiliate to generate multiple plans from workflow definition 
file 6800 in Fig. 68 or the workflow identified as "AssemblyWorkflow." 

1 0 The conditions-to-check received by the Client Interface 134 also include a role/resource 
reassignment condition 7004. When processing role/resource reassignment condition 7004, the 
Client Interface 134 determines if a resource (not shown in Fig. 70) that was automatically 

D assigned by the Client Interface 134 to handle a role 7016 (e.g., Assembler) for the task has been 
=£} overridden by a replacement resource (not shown in Fig. 70) that an enterprise affiliate manually 
IS assigned using the Client Interface 134. Role 7016 corresponds to a responsible-role-property 
O (6806 in Fig. 68 and 701 8 in Fig. 70) for the "Get Parts" activity 6801 in Fig. 68. 

11 In addition, the conditions-to-check received by the Client Interface 134 may include a 
JL new-successor condition 7006. When processing new-successor condition 7006, the Client 
CO Interface 134 checks if a planned-successor 7020 for the task has been replaced with a new 
If) successor, such as a manually entered task or a non-default path for the task entered by the 
H enterprise affiliate using the Client Interface 134. Planned-successor 7020 corresponds to a 

default-successor-property (6808 in Fig. 68 and 7022 in Fig. 70) for "Get Parts" activity 6801. 

The conditions-to-check 7002, 7004, and 7006 are described in greater detail below. 

The Client Interface 134 allows the enterprise affiliate to identify a different set of 
25 conditions-to-check 7002, 7004, and 7006 for each activity in the workflow as shown in Fig. 70. 

In another implementation, the Client Interface 134 allows the enterprise affiliate to identify a 

single set of conditions-to-check for every activity in the workflow. 

The Client Interface 134 may process all conditions-to-check for each task in the plans 

created from the workflow after receiving the request from an enterprise affiliate to optimize the 
30 workflow. In this implementation, the Client Interface 134 would not perform step 6704 as the 

enterprise affiliate would not need to identify the conditions-to-check to the Client Interface 134. 



47 



The Client Interface 134 may also initially receive the request to optimize the workflow 
and receive the conditions-to-check when creating the workflow as described above in reference 
to Fig. 3. In this implementation as shown in Fig. 68, the Client Interface 134 stores optimize 
flags 6810, 6812, and 6814 within workflow definition file 6800 to reflect the conditions-to- 
5 check 7002, 7004, and 7006 in Fig. 70 for the task when created from the activity. In addition, 
the Client Interface 134 may also receive from the enterprise affiliate via a user interface (not 
shown) minimum plan indicators 6816, 6818, and 6820 in Fig. 68 that the Client Interface 134 
stores in association with optimize flags 6810, 6812, and 6814 in workflow definition file 6800. 
Each minimum plan indicator 6816, 6818, and 6820 identifies to the Client Interface 134 the 
10 minimum number of plans that must be created from the workflow before the Client Interface 
134 begins optimization processing for each condition-to-check 7002, 7004, and 7006. 

After receiving the one or more conditions-to-check, the Client Interface 134 receives a 
maximum percentage for each of the conditions-to-check (Step -6706). Each maximum 
percentage reflects the number of times that the Client Interface 134 should find a corresponding 
15 condition-to-check to be true for tasks created from the same activity within the number of plans 
; that are mined by the Client Interface 134 before the Client Interface 134 suggests any 
optimization of the activity in the workflow. Thus, each maximum percentage for each 
condition-to-check represents a threshold before the Client Interface 134 modifies the activity to 
_- improve the workflow in accordance with data mined from tasks created from the activity. As 
20 shown in Fig. 70, the enterprise affiliate identifies to the Client Interface 134 via user interface 
Z 7000 that duration-tolerance-exceeded condition 7002 should be found true in more than 10 
percent (i.e., maximum percentage 7024) of the plans checked before the Client Interface 134 is 
to suggest optimization of the duration-property (6802 in Fig. 68 and 7012 in Fig. 70) for "Get 
Parts" activity 6801. In this implementation, the enterprise affiliate also identifies to the Client 
25 Interface 134 via user interface 7000 that role/resource reassignment condition 7004 should be 
found true in more than 10 percent (i.e., maximum percentage 7026) of the plans checked before 
the Client Interface 134 is to suggest optimization of the responsible-role-property (6806 in Fig. 
68 and 7018 in Fig. 70) for the activity in the workflow. Similarly, the enterprise affiliate also 
identifies to the Client Interface 134 via user interface 7000 that new-successor condition 7006 
30 should be found true in more than 5 percent (i.e., maximum percentage 7028) of the plans 
checked before the Client Interface 134 is to suggest optimization of the default-successor- 
property (6808 in Fig. 68 and 7022 in Fig. 70) for "Get Parts" activity 6801. 
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In one implementation, the Client Interface 134 may initially receive conditions-to-check 
7002, 7004, and 7006 with corresponding maximum percentages 7024, 7026, and 7028 when 
creating the workflow as described above in reference to Fig. 3. In this implementation, the 
Client Interface 134 stores maximum percentages 7024, 7026, and 7028 as maximum percentage 
5 properties 6822, 6824, and 6826 in Fig. 68 within activity 6801 of workflow definition file 6800. 
Thus, the Client Interface 134 is able to retrieve the maximum percentages when performing 
optimization processing described below for the workflow as requested by the enterprise 
affiliate. 

For clarity in the discussion to follow, note that the Client Interface 134 also receives an 
10 optimize flag 6832 for a default-successor-property 6830 of "L Or Rt Handed?" logic activity 
(6828 in Fig. 68 and graphically depicted as 6906 in Fig. 69). Thus, the Client Interface 134 
receives a new-successor condition-to-check for "L Or Rt Handed?" logic activity 6828. As 
-"_ shown in Fig. 68, the Client Interface 134 also receives a minimum plans indicator 6834 and 
„_Z maximum percentage 6836 for processing the new-successor condition for "L Or Rt Handed?" 
is logic activity 6828. 

- 3 After receiving a maximum percentage for each of the conditions-to-check for the task, 

~1 the Client Interface 134 sets a counter for each condition-to-check to zero (Step 6708). The 

Client Interface 134 uses the counter for each condition-to-check to track how many times the 
C-= Client Interface 134 found the condition-to-check to be true within the number of plans checked 
20 by the Client Interface 134. The Client Interface 134 also sets a plan counter to zero 
""f (Step 6710). The Client Interface 134 uses the plan counter to track the number of plans 

checked. 

Next, the Client Interface 134 retrieves a plan created from the workflow (Step 6711). 
To retrieve the plan created from the workflow, the Client Interface 134 uses known WebDAV 

25 protocol methods to parse each plan definition file stored on WebDAV Storage 142 in Fig. 2 to 
find a plan that has a link or URL to the workflow definition file to be optimized by the Client 
Interface 134. For example, Figs. 71A-B depict an exemplary excerpt of plan definition file 
7100 that has a link 7102 (Fig. 7 IB) to workflow definition file 6800 shown in Fig. 68. In this 
example, to find link 7102, the Client Interface 134 may parse plan definition file 7100 for a task 

30 having a unique identifier set to "NONE" 7104 and having a caption 7106 that is set to the same 
value as a name 7108 for the plan. Thus, the Client Interface 134 is able to find and recognize 



49 



that link 7102 matches the location of the workflow that the enterprise affiliate has requested to 
be optimized and retrieves the plan definition file 7100 for further processing. 

In another implementation, the Client Interface 134 may retrieve a plan created from the 
workflow by using known WebDAV protocol methods, such as "PROPFIND," to retrieve all 
5 plans on WebDAV Storage 142 that have a common WebDAV property set to the link or URL 
for workflow definition file 6800 in Fig. 68. For example, the Client Interface 134 may retrieve 
all plans having a WebDAV property named "PROJECT" that is set to link 7102 or 
"http://localhost: 8080/webdav/ProcessGroup2/ Assembly Workflow.xml." In this 

implementation, when the Client Interface 134 performs the process in Fig. 3 to create each plan 
10 from workflow definition file 6800, the Client Interface 134 also creates the WebDAV property 
named "PROJECT" for each plan definition file 7100 and then sets the "PROJECT" property to 
the URL of workflow definition file 6800. The Client Interface 134 may, however, create the 
WebDAV property of the plan for storing the URL to the workflow definition file with a name 
other than "PROJECT." 

15 After retrieving a plan, the Client Interface 134 increments the plan counter (Step 6712). 

Z~ Next, the Client Interface 134 retrieves a task of the plan (Step 6714). In one implementation, 

Z, the Client Interface 134 retrieves a task of the plan by parsing plan definition file 7100 to 
identify a "Get Parts" task 71 1 0 as shown in Fig. 71 A. 

After retrieving a task of the plan, the Client Interface 134 retrieves a planned-task- 

^20 property and an actual-task-property for evaluating the condition-to-check (Step 6716). As 

- previously described above, each retrieved "Get Parts" task 7110 also includes a link or a URL 
(e.g., task URL 71 12 in Fig. 71A) to a task definition file stored on WebDAV Storage 142 in 
Fig. 2. Thus, the Client Interface 134 may retrieve planned-task-property or actual-task-property 
for the task by parsing "Get Parts" task 7110 within plan definition file 7100, by parsing 

25 workflow definition file 6800 in Fig. 68 for the activity used to create the task, by parsing the 
task definition file located at task URL 7106, by accessing WebDAV properties created by the 
Client Interface 134 for storing planned-task-property or actual-task-property in association with 
the task definition file at task URL 7106, or by using any combination of these techniques. 

The planned-task-property and the actual-task-property retrieved by the Client Interface 

30 134 corresponds to the condition-to-check. To evaluate duration-tolerance-exceeded condition 
7002 in Fig. 70, the Client Interface 134 recognizes that the planned-task-property to be 
retrieved includes duration-property 6802 in Fig. 68 and duration-tolerance-property 6804 from 



workflow definition file 6800. In another implementation, the Client Interface 134 may 
calculate duration-property 6802 by determining the difference between a planned-start-date 
7114 in Fig. 71A and a planned-fmish-date 7116 for "Get Parts" task 7110. In this 
implementation, the Client Interface 134 may also store duration-tolerance-property 6804 in Fig. 
5 68 as another property (not shown) of task "Get Parts" 71 10 in Fig. 71 A when the task is created 
from the activity so that the Client Interface 134 can later retrieve the value of duration- 
tolerance-property 6804 without accessing workflow definition file 6800 in Fig. 68. 

Moreover, to evaluate the duration-tolerance-exceeded condition 7002 in Fig. 70, the 
Client Interface 134 recognizes that the actual-task-property to be retrieved includes an actual- 
10 task-duration that the Client Interface 134 may retrieve or derive from actual start and actual 
finish properties of "Get Parts" task 7110. For example, Fig. 72 depicts actual-properties 7202 
for "Get Parts" task 7110 that the Client Interface 134 creates on WebDAV Storage 142 for 
z" recording status and actual data for "Get Parts" task 7110. As shown in Fig. 72, actual- 
properties 7202 include an actual-start-date 7204 and actual-fmish-date 7206 for "Get Parts" 
15 task 7110. As explained above, while managing the execution of the plan, Workflow Engine 
"7 222 in Fig. 2 stores when "Get Parts" task 7110 is started in actual-start-date 7202 and when 
J "Get Parts" task 7110 is completed in actual-finish-date 7206. Thus, the Client Interface 134 
^ may derive the actual-task-duration by obtaining the difference between actual-start-date 7204 
- and actual-finish-date 7206. 

20 The Workflow Engine 222, however, may also store the actual-task-duration as another 

I*- WebDAV property (not shown) of actual-properties 7202 or as a property (not shown) within 
"Get Parts" task 7110. The Client Interface 134 and the Workflow Engine 222 use the same 
structure for each plan. Thus, the Client Interface 134 is able to determine how Workflow 
Engine 222 has stored the actual-task-duration on WebDAV Storage 142 in Fig. 2 so that the 

25 Client Interface 134 may retrieve actual-task-duration for processing. 

In another implementation, the Client Interface 134 allows an enterprise affiliate to 
manually override planned-start-date 7114 in Pig. 71A or planned-finish-date 7116 before the 
"Get Parts" task 7110 is activated. The Client Interface 134 is able to recognize a manual 
override of planned-start-date 7114 or planned-finish-date 7116 via manual override flags (not 

30 shown) stored in association with these two properties in task "Get Parts" 7110. In another 
implementation, the Client Interface 134 is able to recognize a manual override by identifying 
two versions of the same plan that reflect a difference in planned-start-date 71 14 or in planned- 
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stop-date 7116. The Client Interface 134 determines that duration-tolerance-exceeded condition 
is met as the enterprise affiliate has manually overridden either planned-start-date 7114 or 
planned-finish-date 7116 or both. Thus, the Client Interface 134 recognizes that duration- 
property 6802 in Fig. 68 for "Get Parts" activity 6801 does not yet reflect the manual override 
5 and that duration-property 6802 may be optimized in accordance with the difference between the 
override value for planned-start-date 7114 and the override value for planned-finish-date 7116. 

To evaluate role/resource reassignment condition 7004 in Fig. 70, the Client Interface 
134 retrieves a resource-assignment property from "Get Parts" task 7110 to identify if the 
resource-assignment property is set to "Manual," indicating that the role of "Get Parts" task 
10 7110 has been manually assigned by an enterprise affiliate. For example, the Client Interface 
134 recognizes that resource-assignment property 7118 for "Get Parts" task 7110 has a value of 
"Auto" 7120, which reflects that resource 7124 ("JK") has been automatically assigned to the 
O task role (e.g. "Assembler") identified by owner 7122 in Fig. 71 A. Owner 7122 corresponds to 
y. responsible role 6806 of the activity in Fig. 68. Furthermore, the Client Interface 134 is able to 
;f5 recognize that planned-task-property is the same as actual-task-property for this task because no 
O resource reassignment has been found by the Client Interface 134. Thus, the Client Interface 
134 recognizes that no other data needs to be retrieved to evaluate role/resource reassignment 
«_ condition 7004 in Fig. 70 for "Get Parts" task 7110. 

-i The Client Interface 134 also recognizes that if the retrieved resource-assignment 

j£0 property 7118 has a value of "Manual" then a manual reassignment has occurred for "Get Parts" 
O task 7110 and another earlier version of plan definition file 7100 is stored on WebDAV Storage 

La 

142. The Client Interface 134 recognizes that the earlier version of plan definition file 7100 has 
resource 7124 ("JK") that the Client Interface 134 automatically assigned to owner 7122 of "Get 
Parts" task 7110. For example, Figs. 73A-C depict an exemplary excerpt of plan definition file 

25 7300 created by the Client Interface 134 in response to an enterprise affiliate assigning a 
replacement resource 7324 ("MG") to the task role ("Assembler") identified by owner 7322 of 
"Get Parts" task 7310. Owner 7322 also corresponds to responsible role 6806 of "Get Parts" 
activity 6801. Before the plan is completed and before the task corresponding to "Get Parts" 
task 7310 is activated, the Client Interface 134 is able to create plan definition file 7300 as a 

30 later version of plan definition file 7100 in Fig. 71 A so that "Get Parts" task 7310 is identifiable 
as a later version of "Get Parts" task 7110. At the time "Get Parts" task 7310 is created, the 
Client Interface 134 sets resource-assignment property 7318 to have a value of "Manual" 7320. 



The Client Interface 134 then stores plan definition file 7300 on WebDAV Storage 142 as a later 
version of plan definition file 7100 in Fig. 71A. 

The Client Interface 134 may implement versioning by creating a WebDAV property 
named "Version" (not shown) for plan definition files 7100 and 7300. The Client Interface 134 
5 may then set the "Version" property to "First" for plan definition file 7100 when file 7100 is 
created by the Client Interface 134 and set the "Version" property to "Second" for plan 
definition file 7300 when file 7300 is created by the Client Interface 134. Thus, in the event that 
owner 7322 of the "Get Parts" task 7310 has been manually assigned replacement resource 7324 
by an enterprise affiliate using the Client Interface 134, the Client Interface 134 is able to 

10 recognize that plan definition file 7300 is a later version of plan definition file 7100. 
Furthermore, the Client Interface 134 is able to recognize that plan definition file 7300 in Fig. 
73 A has the actual-task-property (resource-assignment property 7318) and plan definition file 

O 7100 in Fig. 71 A has the planned-task-property (resource- assignment property 7118) for 

•3 evaluating role/resource reassignment condition 7004 in Fig. 70. 

?B In another implementation, to evaluate role/resource reassignment condition 7004, the 

D Client Interface 134 may retrieve the version property (not shown) of plan definition file 7100. 
y[ If the version property of plan definition file 7100 is not set to "First," the Client Interface 134 
! ;L may then retrieve a later version of plan definition file 7100, such as plan definition file 7300. 
Co The Client Interface 134 may then determine if "Get Parts" task 73 10 in plan definition file 7300 
;|f) has a resource (i.e., "MG" resource 7324) assigned to owner 7322 that is different from the 
Q resource (i.e., "TK" resource 7124) assigned to corresponding owner 7122 of "Get Parts" task 
7110. 

To evaluate new-successor condition 7006 in Fig. 70, the Client Interface 134 retrieves 
successor 7126 in plan definition file 7100 for the actual-task-property of the task and retrieves 
25 default-successor-property 6808 in Fig. 68 of the corresponding activity in workflow definition 
file 6800 for the planned-task-property. As discussed below, when the actual-task-property 
differs from the planned-task-property, the Client Interface 134 is able to recognize that an 
enterprise affiliate has added a new successor task to or chosen a non-default path from the task 
of the plan. 

30 Returning to Fig. 67 A, after retrieving planned- task-property and actual-task-property for 

evaluating the condition-to-check, the Client Interface 134 determines if the condition-to-check 
has been met or is true (Step 6718). For example, to determine if duration-tolerance-exceeded 
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condition 7002 in Fig. 70 is met for "Get Parts" task 71 10, the Client Interface 134 determines if 
the actual-task-duration for "Get Parts" task 71 10 (as derived or as retrieved) is longer or shorter 
than the value of duration-property 6802 in Fig. 68 plus or minus the value of duration- 
tolerance-property 6804. To determine if role/resource reassignment condition 7004 in Fig. 70 
5 is met for task 7102, the Client Interface 134 determines if the retrieved resource-assignment 
property 7118 has a value of "Manual" as discussed above. To determine if new-successor 
condition 7006 in Fig. 70 is met for "Get Parts" task 7110, the Client Interface 134 compares 
successor 7126 for "Get Parts" task 7110 in plan definition file 7100 to default-successor- 
property 6808 of the corresponding "Get Parts" activity 6801 in workflow definition file 6800 in 
10 Fig. 68. 

If the condition-to-check is true, the Client Interface 134 increments the counter for the 
condition-to-check (Step 6720). Next, the Client Interface 134 logs or stores optimization 
O information for the activity (Step 6721). The optimization information includes the condition- 
er to-check, the activity, the task, the planned-task-property, and the actual-task-property. The 
jfe Client Interface 134 may store the optimization information for the activity so that the Client 
O Interface 134 is able to quickly reference the optimization information when generating an 
optimization suggestion for improving the workflow or when implementing the optimization 
■L suggestion. For example, the optimization information may be organized in a database table 
fn format (not shown) so that each condition-to-check for each activity of the workflow has a 
jp corresponding database table. The Client Interface 134 may then store the remaining 
O optimization information for the task (i.e., task, the planned-task-property and the actual-task- 
property) as a record in each database table. Thus, for an activity of the workflow, the Client 
Interface 134 is able to determine the average actual duration for tasks that correspond to the 
activity by assessing record entries in the database table (not shown) for duration-tolerance- 
25 exceeded condition 7002 in Fig. 70. Similarly, in another database table (not shown) organized 
for the role/resource reassignment condition 7004 associated with the activity, the Client 
Interface 134 is able to assess record entries to determine a resource that is most often manually 
assigned to an owner of a task (that corresponds to a responsible role of the activity). Thus, the 
Client Interface 134 is able to obtain any summary of logged optimization information for an 
3 0 activity o f a workflow . 

Next, the Client Interface 134 determines if there are more conditions-to-check in the 
task (Step 6722). For example, if an enterprise affiliate selected conditions-to-check 7002, 
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7004, and 7006 in Fig. 70 for "Get Parts" activity 6801 in Fig. 68 via user interface 7000 
displayed by the Client Interface 134, then the Client Interface 134 may determine that there are 
two more conditions-to-check for task 7110. If the Client Interface 134 determines that there are 
more conditions-to-check for the task, the Client Interface 134 then selects the next condition-to- 
5 check for the task (Step 6723). After selecting the next condition-to-check for the task, the 
Client Interface 134 continues processing at step 6716. 

If it is determined that there are no more conditions-to-check for the task, the Client 
Interface 134 determines if all tasks of the plan have been checked (Step 6724). The Client 
Interface 134 determines that all tasks of the plan have been checked when the task does not 

10 have a successor task. For example, the Client Interface 134 is able to recognize that "Get 
Parts" task 7110 in Fig. 71 A has successor 7126 that identifies a name 7128 ("Task_5") of the 
next task in the plan. Thus, the Client Interface 134 recognizes that not all tasks of the plan have 

Z been checked. The. Client Interface 134, however, may also determine that all tasks of the plan 
have been checked when the Client Interface 134 determines that there are no more tasks (i.e., 

%3 71 10, 7130, 7140, and 7150 in Figs. 71 A-B) to be retrieved from plan definition file 7100. 

Z If it is determined that all tasks of the plan have not been checked, the Client Interface 

Z 134 retrieves the next task in the plan (Step 6726). As shown in Fig. 71A, the Client Interface 
134 retrieves "L Or Rt Handed?" task 7130 as the next task in plan definition file 7100. The 

'I Client Interface 134 may retrieve "L Or Rt Handed?" task 7130 as the next task by recognizing 

2D that task 7130 has a name 7132 that matches name 7128 of successor 7126 of "Get Parts" task 

= 71 10. After retrieving the next task, the Client Interface 134 continues processing at step 6716. 

If it is determined that all tasks of the plan have been checked, the Client Interface 134 
then determines if all plans that have been created from the workflow have been checked (Step 
6728). If all plans that have been created from the workflow. have not been checked, the Client 

25 Interface 134 retrieves the next plan from WebDAV Storage 142 (Step 6730). After retrieving 
the next plan, the Client Interface 134 continues processing at step 6712. 

If it is determined that all plans that have been created from the workflow have been 
checked, the Client Interface 134 then determines if the maximum percentage for any condition- 
to-check is exceeded for any activity in the workflow (Step 6732 in Fig. 67B). To determine if 

30 the maximum percentage for any condition-to-check is exceeded, the Client Interface 134 
calculates a percentage-met for each condition-to-check for each activity in the workflow. The 
Client Interface 134 calculates each percentage-met by dividing the number of times that each 
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condition-to-check was found true (i.e., value of the condition-to-check counter) by the number 
of plans checked (i.e., value of plan counter) times one hundred (100). The Client Interface 134 
then compares the maximum percentage for each condition-to-check with each calculated 
percentage-met to determine if any maximum percentage has been exceeded for any activity in 
5 the workflow. 

If the maximum percentage for any condition-to-check is not exceeded, the Client 
Interface 134 completes processing. If the maximum percentage for any condition-to -check for 
any activity is exceeded, the Client Interface 134 generates a workflow optimization suggestion 
for each condition-to-check for each activity that exceeds the maximum percentage 
10 corresponding to the condition-to-check (Step 6734). For example, assume that an enterprise 
affiliate has indicated to the Client Interface 134 that optimization conditions-to-check 7002, 
7004, and 7006 in Fig. 70 are to be evaluated for tasks created from "Get Parts" activity 6801 in 
— workflow definition file 6800. In addition, assume that the enterprise affiliate has generated one 
= hundred (100) plans from workflow definition file 6800 using the Client Interface 134. Further 
F5 assume that the eleven (11) tasks corresponding to "Get Parts" activity 6801 in eleven (11) of 
the plans have the following: 

(1) an actual-start-date and an actual-finish-date that the Client Interface 134 determines 
exceeds the value of duration-property plus the value of duration-tolerance-property; 
£ (2) a resource-assignment property that has been previously set to "Manual" by the 

20 Client Interface 134 in response to the enterprise affiliate manually assigning a replacement 
z resource to the task owner (corresponds to responsible role of "Get Parts" activity); and 

(3) a successor that the Client Interface 134 determines does not correspond to default- 
successor-property of "Get Parts" activity 6801. 

Using this example, the Client Interface 134, when performing the preceding processing 
25 steps, is able to identify that maximum percentage 7024 of 10% for duration-tolerance-exceeded 
condition 7002 in Fig. 70 for "Get Parts" activity 6801 is exceeded as eleven tasks out of one 
hundred tasks (11%) that correspond to "Get Parts" activity 6801 have an actual-duration that 
exceeds duration-property of "Get Parts" activity 6801. As a result, the Client Interface 134 
generates a workflow optimization suggestion that indicates duration-property 6802 in Fig. 68 
30 for "Get Parts" activity 6801 may be improved. Similarly, the Client Interface 134 is able to 
identify that maximum percentage 7026 of 10% for role/resource reassignment condition 7004 
in Fig. 70 for "Get Parts" activity 6801 is exceeded as eleven tasks out of one hundred tasks 
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(11%) that correspond to "Get Parts" activity 6801 have a manually assigned replacement 
resource. Thus, the Client Interface 134 generates another workflow optimization suggestion 
that indicates responsible-role-property 6806 in Fig. 68 for "Get Parts" activity 6801 may be 
improved. In addition, the Client Interface 134 is able to identify that maximum percentage 
5 7028 of 5% for new-successor condition 7006 in Fig. 70 for "Get Parts" activity 6801 is 
exceeded as eleven tasks out of one hundred tasks (11%) that correspond to "Get Parts" activity 
6801 have a successor that does not correspond to the successor of "Get Parts" activity 6801. 
Therefore, the Client Interface 134 generates a workflow optimization suggestion that indicates 
default-successor-property 6808 in Fig. 68 for "Get Parts" activity 6801 may be changed to 
10 reflect the addition of a manually entered task or to reflect a manually selected alternate default 
path for the workflow. 

Continuing with Fig. 67B, after generating a workflow optimization suggestion for each 
r: condition-to-check for each activity that exceeds a corresponding maximum percentage, the 
Client Interface 134 notifies the enterprise affiliate of the workflow optimization suggestions 
+5 (Step 6736). In one implementation, the Client Interface 134 may notify the enterprise affiliate 
I via a dialog box (not shown) displayed by the Client Interface 134 in association with the same 
r: user interface that the enterprise affiliate used to initiate the request to optimize the workflow. 

In another implementation, the Client Interface 134 is able to notify the enterprise 
- affiliate by sending an e-mail message to the enterprise affiliate via network 108 in Fig. 1. The 
20 Client Interface 134 is able to identify an e-mail address for the enterprise affiliate by accessing 
: a user profile for the enterprise affiliate that is stored on WebDAV Storage 142 as discussed 
above. 

After notifying the enterprise affiliate of the workflow optimization suggestions, the 
Client Interface 134 determines if any of the workflow optimization suggestions are to be 

25 implemented (Step 6738). In one implementation, the enterprise affiliate indicates to the Client 
Interface 134 which, if any, of the workflow optimization suggestions are to be implemented by 
actuating a button (not shown) next to each workflow optimization suggestion displayed by the 
Client Interface 134 in association with the same user interface that the enterprise affiliate used 
to initiate the request to optimize the workflow. In another implementation, the Client Interface 

30 134 is configured to receive an e-mail reply to the notification sent by the Client Interface 134 
and to recognize workflow optimization suggestions within the reply that the enterprise affiliate 
has selected to be implemented. 
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If it is determined that there are no workflow optimization suggestions to implement, the 
Client Interface 134 completes processing. If it is determined that there are workflow 
optimization suggestions to implement, the Client Interface 134 identifies the activity and the 
condition-to-check that correspond to the first workflow optimization suggestion to implement 
5 (Step 6740 in Fig. 67C). Next, the Client Interface 134 determines if the condition-to-check 
corresponds to a duration-tolerance-exceeded condition (Step 6742). If the condition-to-check 
corresponds to a duration-tolerance-exceeded condition, the Client Interface 134 sets the 
duration for the activity to the average of actual-task-duration (Step 6744). As described above, 
the Client Interface 134 may derive the actual-task-duration for each task that corresponds to the 
10 activity by calculating the difference between the actual-start-date and the actual-finish-date for 
each task. For the example shown in Fig. 74, which depicts actual-properties 7402 for "Get 
Parts" task 7310 in Fig. 73A, the difference between actual-start-date 7404 (i.e., year-2001 
q month-8 day-2 hour-8) and actual-finish-date 7406 (i.e., year-2001 month-8 day-2 hour-12) was 
four (4) hours. Thus, the Client Interface 134 derives the actual-task-duration to be four (4) 
«P5 hours for "Get Parts" task 7310. Assuming that the actual-task-duration for "Get Parts" task 
□ 7310 is representative of the one hundred tasks created from "Get Parts" activity 6801 in Fig. 68 
jjf that are evaluated in the one hundred plans checked by the Client Interface 134 while 
e_ performing this process, the Client Interface 134 sets the duration for "Get Parts" activity 6801 
-~ to be four (4) hours to optimize workflow definition file 6800. Fig. 75 depicts an exemplary 
jib workflow definition file 7500 that reflects the optimization of workflow definition file 6800 for 
O a duration-tolerance-exceeded condition. As shown in Fig. 75, the Client Interface 134 has set 
the value of duration-property 7502 for "Get Parts" activity 7501 to "4," to reflect the average 
actual-task-duration derived by the Client Interface 134. Thus, when an enterprise affiliate 
requests the Client Interface 134 to generate a plan from the workflow identified as "Assembly 
25 Work flow," the Client Interface 134 will create the plan from optimized workflow definition 
file 7500. In another implementation, the Client Interface 134 may lower or raise duration- 
property 7502 in accordance with the average of actual-task-duration of all tasks in all plans 
corresponding to "Get Parts" activity 6801. In addition, the Client Interface 134 may lower or 
raise duration-property 7502 in accordance with the average of actual-task-duration of tasks 
30 entered as log information for "Get Parts" activity 6801. 

If the condition-to-check for the activity does not correspond to a duration-tolerance- 
exceeded condition, the Client Interface 134 determines if the condition-to-check corresponds to 



a task role/resource reassignment condition (Step 6746). If the condition-to-check for the 
activity corresponds to a task role/resource reassignment condition, the Client Interface 134 
determines if any task role was assigned to a resource without the capability to perform the task 
role (Step 6748). To identify if any task role was assigned to a resource without the capability to 
5 perform the task role, the Client Interface 134 first retrieves from the logged optimization 
information each task that has resource-assignment property set to "Manual" in order to identify 
the task role identified by each task owner and the identification of each resource that was 
manually assigned by an enterprise affiliate to handle the task role. For example, the Client 
Interface 134 may retrieve "Get Parts" task 7310 that has resource-assignment property 7318 set 
10 to "Manual." The Client Interface 134 is then able to identify that owner 7322 has the task role 
of "Assembler" 7323 for "Get Parts" task 7310 and that resource 7324 identifies "MG" 7325 as 
the manually assigned resource. 

The Client Interface 134 then accesses the role profile for the identified task role, 
"Assembler" 7323. As previously discussed, the Client Interface 134 may store role profiles 
•55 identified by an enterprise affiliate for a workflow in a single file or in multiple files on 
=~ WebDAV Storage 142. The single file or multiple files each have a link to an associated 
_= workflow so that the Client Interface 134 is able to access the files with roles for the workflow. 

In one implementation shown in Fig. 76, the Client Interface 134 links a workflow roles file 
* 7600 to workflow definition file 6800 in Fig. 68 based on each having the same name (i.e., 6828 
20 and 7602, respectively). The Client Interface 134 is then able to access workflow role profiles 
Z 7604, 7606, and 7608 that have been previously stored in file 7600 by the Client Interface 134. 
The Client Interface 134 is also able to associate the task role of "Assembler" 7323 with role 
profile 7604 based on the role profile having the same name 7612 or same unique identifier 
7614 as "Assembler" task role 7323. To identify if the resource identified as "MG" 7325 has 
25 the capability to handle "Assembler" task role 7323, the Client Interface 134 determines if the 
manually assigned resource is among the capable resources listed for the role profile associated 
with the task role. For example, as shown in Fig. 76, the Client Interface 134 is able to conclude 
that "MG" 7325 is not listed among capable resources 7610 for "Assembler" role profile 7604. 

In another implementation, the Client Interface 134 may arrive at the same conclusion by 
30 determining that the manually assigned resource did not share a skill with the identified task 
role. For example, the Client Interface 134 may retrieve resource file 7700 in Fig. 77 that was 
previously created and stored by the Client Interface 134 on WebDAV Storage 142. Resource 



file 7700 has resource profiles 7702, 7704, and 7706 that an enterprise affiliate identified to the 
Client Interface 134 for potential assignment to tasks in a plan created from a workflow using 
the Client Interface 134. As shown in Fig. 77, the Client Interface 134 is able to identify 
resource profile 7704 as having the same unique identifier ("MG" 7708) as the resource 
5 identified as "MG" 7325 in "Get Parts" task 7310. The Client Interface 134 is also able to 
identify that resource profile 7704 for the resource "MG" has a skill 7710, but that skill 7710 is 
not found among skills 7614 in Fig. 76 identified in "Assembler" role profile 7604. Thus, the 
Client Interface 134 is able to conclude that resource "MG" does not have the capability to 
handle the task role of "Assembler" 7323 for "Get Parts" task 7310. 
10 If it is determined that a task role was assigned a resource without the capability to 

perform the task role, the Client Interface 134 sets the responsible role of the corresponding 
activity to a different role that corresponds to a resource-most-often-assigned (Step 6750). The 
O Client Interface 134 is able to recognize the resource-most-often-assigned by accessing each 
'% manually assigned resource 7324 for "Get Parts" task 7110 in the logged optimization 
•*§5 information. For example, the Client Interface 134 may conclude that the enterprise affiliate 
□ most often manually assigns the resource "MG" associated with resource profile 7704 to handle 
the "Assembler" task role 7323. Based on this conclusion, the Client Interface 134 then checks 
^ capable resources for role profiles other than "Assembler" role profile 7604 to identify if the 
m resource-most-often-assigned (e.g., "MG") is associated with another role that may be assigned 
*2f0 by the Client Interface 134 to responsible role 6806 for activity 6801. Accessing the exemplary 
u role profiles in Fig. 76, the Client Interface 134 checks capable resources 7616 and 7618 and is 
able to identify that resource "MG" is among capable resources 7618 for role profile 7608 that 
corresponds to role 7620, identified as "Gopher." 

In another implementation, the Client Interface 134 may compare a skill of the resource- 
25 most-often-assigned (e.g., "MG") to the skills in role profiles other than "Assembler" role 
profile 7604 in order to identify an optimal role that may be assigned to responsible role 6806 
for activity 6801. For example, the Client Interface 134 may compare skill 7710 of "MG" 
resource profile 7704 to skills 7622 and 7624 of role profiles 7606 and 7608, respecively. In 
this example, the Client Interface 134 is able to identify that skill 7622 of role profile 7606 
30 matches skill 7624 of role profile 7608 corresponding to "Gopher" role 7620. 

The Client Interface 134 then sets responsible role 6806 for "Get Parts" activity 6801 to 
"Gopher" role 7620 to optimize workflow definition file 6800. Fig. 78 depicts an exemplary 



workflow definition file 7800 created by the Client Interface 134 to reflect the optimization of 
workflow definition file 6800 for the role/resource reassignment condition. As shown in Fig. 
78, the Client Interface 134 has set responsible-role 7802 to "Gopher" role 7804 for "Get Parts" 
activity 7801. Thus, when an enterprise affiliate requests the Client Interface 134 to generate a 
5 plan from the workflow identified as "Assembly Workflow," the Client Interface 134 creates the 
plan from optimized workflow definition file 7800. The Client Interface 134 then automatically 
assigns a resource with the capability to handle the task role corresponding to the optimized 
responsible role of the activity so that the enterprise affiliate need not perform a manual override 
of the automatically assigned resource. 
10 Note that workflow definition file 7800 may also reflect the optimization of "Get Parts" 

activity 6801 for any other earlier optimization by the Client Interface 134, such as the 
optimization of "Get Parts" activity for duration-tolerance-exceeded condition 7002 in Fig. 70. 
o If it is determined that no task role was manually assigned a resource without the 

"= capability to perform the task role, the Client Interface 134 determines if any task role was 
|5 assigned a resource with a different skill level (Step 6752). To identify if any task role was 
~ assigned a resource with a different skill level, the Client Interface 134 compares the skills 
.;■]; associated with the task role to the skills associated with each resource that has been manually 
assigned to the task role. For example, the Client Interface 134 may access role profile 7902 in 
} Fig. 79 to identify skills 7904 for "Assembler" task role 7323 assigned to "Get Parts" task 7310 
20 in Fig. 73 A. Note that the Client Interface 134 recognizes that capable resources 7906 includes 
_I the resource identified as "MG" 7325, which the Client Interface 134 has previously determined 
to have been manually assigned to the "Assembler" task role 7323. Therefore, the Client 
Interface 134 compares skills 7904 for "Assembler" task role 7323 to skill 7710 in resource 
profile 7704 for resource "MG." In this example, the Client Interface 134 recognizes that skill 
25 7710 for resource "MG" has a unique skill identifier "1" that is the same as a skill 7908 for 
"Assembler" task role 7323. The Client Interface 134 also recognizes that skill 7710 for 
resource "MG" has an associated skill strength 7712 of "7" while skill 7908 for "Assembler" 
task role 7323 has an associated skill strength 7910 of "5." Thus, the Client Interface 134 
recognizes that skill 7710 for resource "MG" has a different skill strength or skill level than skill 
30 7908 for "Assembler" task role 7323 of "Get Parts" task 73 10 in Fig. 73A. 

If it is determined that a task role was assigned a resource with a different skill level, the 
Client Interface 134 sets a skill level of the responsible role of the activity to a skill level of 



resource-most-often-assigned (Step 6754). As previously discussed, the Client Interface 134 
may identify that resource "MG" is the resource-most-often-assigned by an enterprise affiliate to 
"Assembler" task role 7323 of "Get Parts" task 7310. Thus, the Client Interface 134 may then 
set skill strength 7910 associated with skill 7908 in "Assembler" role profile 7902 to the same 
5 level as skill strength 7712 associated with skill 7710 in "MG" resource profile. The Client 
Interface 134 does not change workflow definition plan 6800 in this instance. The Client 
Interface 134, however, still optimizes the workflow definition plan 6800 by improving 
"Assembler" role profile 7902 that is assigned to responsible role 6806 for "Get Parts" activity 
6801. Thus, when an enterprise affiliate requests the Client Interface 134 to generate a plan 
10 from the workflow identified as "Assembly Workflow," the Client Interface 134 will create the 
plan from workflow definition file 6800 and automatically assign a resource that has a sufficient 
strength to handle the task role for "Get Parts" activity 6801. In another implementation, a skill 
o and associated skill strength for responsible role for an activity, such as responsible role 6806 of 
% "Get Parts" activity 6801, may be stored as properties (not shown) of activity 6801. In this 
1=5 implementation, the Client Interface 134 would adjust the skill strength for responsible role 
□ 6806 without impacting the assignment of "Assembler" role profile 7902 to another responsible 
: role in another activity of workflow definition file 6800. 

Turning now to Fig. 67D, if it is determined that the condition-to-check for the activity 
ffl does not correspond to a task role/resource reassignment condition, the Client Interface 134 
determines if the condition-to-check corresponds to a new-successor condition (Step 6756 in 
O Fig. 67D). If it is determined that the condition-to-check for the activity corresponds to a new- 
successor condition, the Client Interface 134 determines if the new successor corresponds to a 
non-default-path of the activity (Step 6758). As previously discussed, when processing new- 
successor condition 7006 in Fig. 70, the Client Interface 134 stores each task in the optimization 
25 information log that has a successor that is different from the successor of the activity from 
which the task was created by the Client Interface 134. The Client Interface 134 recognizes the 
different successor of the task as a new successor for the corresponding activity. For example, 
the Client Interface 134 may have generated a workflow optimization suggestion for "L Or Rt 
Handed?" logic activity 6828 in Fig. 68 based on the requested new-successor condition (i.e., 
30 optimize flag 6832 for default-successor-property 6830) being met for task 7330 in accordance 
with methods and systems consistent with this invention. When performing processing for 
implementing this workflow optimization suggestion, the Client Interface 134 identifies that "L 
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Or Rt Handed?" logic activity 6828 has a default-successor property 6830 and one outgoing path 
6838 that are both set to "52," which the Client Interface 134 recognizes as a unique identifier or 
link 6844 for "Right" activity 6842. Thus, the Client Interface 134 is able to identify that the 
outgoing default-path of "L Or Rt Handed?" logic activity 6828 includes "Right" activity 6842. 
5 The Client Interface 134 also recognizes that "L Or Rt Handed?" logic activity has another 
outgoing path 6840 that is set to "51," which the Client Interface 134 recognizes as a unique 
identifier or link 6848 for "Left" activity 6846. Thus, the Client Interface 134 is able to identify 
that the outgoing non-default-path of "L Or Rt Handed?" logic activity 6828 includes "Left" 
activity 6846. The Client Interface 134 also recognizes that "L Or Rt Handed?" task 7330 has a 
10 successor 7332 identified as "Task_16," which the Client Interface 134 recognizes as 
corresponding to a link name 7342 for "Left" task 7340. Hence, the Client Interface 134 is able 
to recognize that successor 7332 of "L Or Rt Handed?" task 7330 is different from the outgoing 
O default-path of "L Or Rt Handed?" logic activity 6828 as identified . by default-successor 
J"- property 6830. Thus, the Client Interface 134 identifies successor 7332 as a new successor for 
rfe "L Or Rt Handed?" logic activity 6828. The Client Interface 134 also recognizes that successor 
Q 7332 (i.e., "Left" task 7340) corresponds to the outgoing non-default-path of "L Or Rt 
2 Handed?" logic activity 6828, which includes "Left" activity 6846. 

;!L If it is determined that the new successor corresponds to a non-default-path of the 

-\1 activity, the Client Interface 134 changes the non-default-path of the activity to be the new 
g0 default-path of the activity (Step 6760). To change the non-default-path of "L Or Rt Handed?" 
O logic activity 6828, the Client Interface 134 sets default-successor-property 6830 to be the same 
as the other outgoing path 6840 or link 6848 for "Left" activity 6846. As shown in Fig. 78, 
exemplary workflow definition file 7800 created by the Client Interface 134 reflects the 
optimization of workflow definition file 6800 for the role/resource reassignment condition and 
25 also reflects the optimization of workflow definition file 6800 for the new-successor condition. 
The Client Interface 134 sets default-successor-property 7812 of "L Or Rt Handed?" logic 
activity 7810 to be the same as the other outgoing path 7814 or link 7816 for "Left" activity 
7818. Thus, when an enterprise affiliate requests the Client Interface 134 to generate a plan 
from the workflow identified as "Assembly Workflow," the Client Interface 134 will create the 
30 plan from workflow definition file 7800 and generate tasks for the plan that correspond to 
activities (i.e., "Left" activity 7818 and "Left Special" activity 7820) in the new default-path of 
"L Or Rt Handed?" logic activity 7810. Fig. 80 depicts an exemplary graphical representation 



8002 displayed by the Client Interface 134 to reflect the optimized workflow definition file 7800 
in Fig. 78. As shown in Fig. 80, the new default-path is graphically displayed by the Client 
Interface 134 as a solid line 8008 that leads to "Left" activity 8010 and "Left Special" activity 
8012. The non-default-path is graphically displayed by the Client Interface 134 as a dashed line 
5 8014 that leads to "Right" activity 8016. Thus, the Client Interface 134 provides the enterprise 
affiliate with a visual indication of the optimization of "Assembly Workflow" for the new- 
successor condition. 

If it is determined that the new successor does not correspond to a non-default-path of 
the activity, the Client Interface 134 determines if the new successor corresponds to any activity 

1 0 in the workflow definition file (Step 6762). To determine if the new successor corresponds to 
any activity in the workflow definition file, the Client Interface 134 compares the new successor 
of the logged task to every activity in the workflow definition file. For example, the Client 
Interface 134 may have generated a workflow optimization suggestion for "L Or Rt Handed?" 
logic activity 7810 in Fig. 78 based on the enterprise affiliate requesting optimization of 

1=5 "Assembly Workflow" as defined by workflow definition file 7800 and based on the requested 
new-successor condition being met for "L Or Rt Handed?" task 8130 in Fig. 81 A in accordance 
with methods and systems consistent with this invention. In this example, when performing 
processing for implementing this workflow optimization suggestion, the Client Interface 134 

~_ identifies that "L Or Rt Handed?" logic activity 7810 has a default-successor property 7812 and 

20 one outgoing path 7814 that are both set to "51," which the Client Interface 134 recognizes as a 
unique identifier or link 7816 for "Left" activity 7818. Thus, the Client Interface 134 is able to 
identify that the outgoing default-path of "L Or Rt Handed?" logic activity 7810 includes "Left" 
activity 7818. The Client Interface 134 also recognizes that "L Or Rt Handed?" logic activity 
7810 has another outgoing path 7815 that is set to "52," which the Client Interface 134 

25 recognizes as a unique identifier or link 7822 for "Right" activity 7824. Thus, the Client 
Interface 134 identifies outgoing path 7815 as the non-default-path of "L Or Rt Handed?" logic 
activity 7810. In addition, the Client Interface 134 is able to identify that "L Or Rt Handed?" 
task 8130 has a successor 8132 identified as "Task_19," which the Client Interface 134 
recognizes as corresponding to a link name 8162 for "Left Special" task 8160. Hence, the Client 

30 Interface 134 is able to determine that successor 8132 of "L Or Rt Handed?" task 8130 does not 
correspond to the non-default-path of "L Or Rt Handed?" activity 6828 but does correspond to 
another activity in workflow definition file 7800. 
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If it is determined that the new successor corresponds to an activity in the workflow 
definition file, the Client Interface 134 changes the successor of the activity to correspond to the 
new successor (Step 6764). In addition, when performing the process to change the successor of 
the activity to correspond to the new successor, the Client Interface 134 may also remove any 
5 activities that are no longer part of a path through the workflow. For example, the Client 
Interface 134 recognizes that default-successor-property 7812 needs to be set to link 7826 for 
"Left Special" activity 7820, which corresponds to "Left Special" task 8160. In addition, the 
Client Interface 134 is able to identify that no other activity in workflow definition file 7800 has 
a predecessor or a successor with a link to "Left" activity 7818. Thus, the Client Interface 134 is 
10 able to further optimize workflow definition file 7800 by removing "Left" activity 7818. As 
shown in Fig. 82, exemplary workflow definition file 8200 created by the Client Interface 134 
reflects the optimization of workflow definition file 7800 for the new-successor condition. The 
O Client Interface 134 sets default-successor-property 8212 of "L Or Rt Handed?" logic activity 
% 8210 to be the same as link 8222 for "Left Special" activity 8220. The Client Interface 134 also 
±5 removes "Left" activity 7818 (not shown in Fig. 82) and sets a predecessor 8226 of "Left 
C3 Special" activity 8220 to a link 8228 for "L Or Rt Handed?" logic activity to complete a default- 
jl path for optimized workflow definition file 8200. Thus, when an enterprise affiliate requests the 
!L Client Interface 134 to generate a plan from the workflow identified as "Assembly Workflow," 
00 the Client Interface 134 will create the plan from workflow definition file 8200 and generate 
j§0 tasks for the plan that correspond to activities (i.e., "Left Special" activity 8220) in the default- 
er path of "L Or Rt Handed?" logic activity 8210. Fig. 83 depicts an exemplary graphical 
representation 8302 displayed by the Client Interface 134 to reflect the optimized workflow 
definition file 8200 in Fig. 82. As shown in Fig. 83, the default-path graphically displayed by 
the Client Interface 134 as a solid line 8308 leads from "L Or Rt Handed? logic activity 8306 to 
25 "Left Special" activity 8312, rather than "Left" activity 7818, which has been removed by the 
Client Interface 134 as a result of implementing the optimization suggestion for workflow 
definition file 8200. 

If it is determined that the new successor does not correspond to an activity in the 
workflow definition file, the Client Interface 134 adds a new activity to the workflow definition 
30 file that corresponds to the new successor (Step 6766). To add a new activity to the workflow 
definition file, the Client Interface 134 changes the successor of the activity associated with the 
optimization suggestion to a new link for the new activity. The Client Interface 134 then creates 



the new activity with properties, predecessors, and successors that are consistent with the 
properties, predecessors, and successors for new tasks that the Client Interface 134 has identified 
exit in the plan but have no corresponding activity in the workflow definition file. The Client 
Interface 134 recognizes that each task in a plan has the same unique identifier or link as the 
activity from which the task was created by the Client Interface 134. New tasks that are 
manually added by the enterprise affiliate using the Client Interface 134 do not have a unique 
identifier or link to any activity in the workflow definition file. For example, the Client 
Interface 134 may have generated a workflow optimization suggestion for "Get Parts" activity 
6801 in Fig. 68 based on the enterprise affiliate requesting optimization of "Assembly 
Workflow" as defined by workflow definition file 6800 and based on requested new-successor 
condition 7006 being met for "Get Parts" task 8410 in Fig. 84 in accordance with methods and 
systems consistent with this invention. In this example, when performing processing for 
implementing this workflow optimization suggestion, the Client Interface 134 identifies that 
"Get Parts" task 8410 has a successor 8426 identified as "Task_20," which the Client Interface 
134 recognizes as corresponding to a link name 8472 for "Get Fasteners" task 8470. The Client 
Interface 134 is further able to recognize that "Get Fasteners" task 8470 does have a unique 
identifier or link to another activity in workflow definition file 6800. Hence, the Client Interface 
134 is able to recognize that successor 8426 for "Get Parts" task 8410 identifies a new successor 
(new activity corresponding to "Get Fasteners" task 8470) for "Get Parts" activity 6801. 

Fig. 85 depicts an exemplary workflow definition file 8500 created by the Client 
Interface 134 to reflect the optimization of workflow definition file 6800 for new-successor 
condition 7006 requested by the enterprise affiliate for "Get Parts" activity 6801. As shown in 
Fig. 85, the Client interface 134 has added the new "Get Fasteners" activity 8550 that has a 
unique identifier 8552 to workflow definition file 8500 for "Assembly Workflow." The Client 
Interface 134 has created "Get Fasteners" activity 8550 to have a name 8554 and properties 
8556 that correspond to "Get Fasteners" task 8470. Furthermore, to complete the addition of 
new tasks corresponding to the new successor for "Get Parts" activity 8501, the Client Interface 
134 has set successor 8502 of "Get Parts" activity to link 8552 of "Get Fasteners" activity 8550 
and set predecessor 8562 of "R Or Lt Handed?" logic activity 8560 to link 8552 of "Get 
Fasteners" activity 8550. Fig. 86 depicts an exemplary graphical representation 8602 displayed 
by the Client Interface 134 to reflect the optimized workflow definition file 8500 in Fig. 85. As 
shown in Fig. 86, the Client Interface 134 has added "Get Fasteners" activity (graphically 
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depicted as 8606) between "Get Parts" activity 8604 and "R Or Lt Handed?" logic activity 8608. 
In this example, when an enterprise affiliate requests the Client Interface 134 to generate a plan 
from the workflow identified as "Assembly Workflow," the Client Interface 134 will create the 
plan from workflow definition file 8500 and generate a task for the plan that corresponds to "Get 
Fasteners" activity 8550 saving the enterprise affiliate significant time and costs in preparing the 
plan as the enterprise affiliate no longer has to manually enter the "Get Fasteners" task. 

After implementing the workflow optimization suggestion corresponding to the 
condition-to-check for the activity in steps 6744, 6750, 6754 6760, 6764, and 6766, the Client 
Interface 134 determines if there are more workflow optimization suggestions to implement 
(Step 6768). 

If it is determined that there are more workflow optimization suggestions to implement, 
the Client Interface 134 identifies the activity and the condition-to-check that corresponds to the 
next workflow optimization suggestion to implement (Step 6770). Next, the Client Interface 
134 continues processing at step 6742 for the next workflow optimization suggestion to 
implement. 

If it is determined that there are no more workflow optimization suggestions to 
implement, the Client Interface 134 saves the optimized workflow (Step 6772). The Client 
Interface 134 may save optimized workflow definition files 7800, 8200 and 8500 as new 
workflow definition files, a version of workflow definition file 6800, or in place of workflow 
definition file 6800 on WebDAV Storage 142 in Fig. 2. 

While various embodiments of the application have been described, it will be apparent to 
those of ordinary skill in the art that many more embodiments and implementations are possible 
that are within the scope of this invention. Accordingly, the invention is not to be restricted 
except in light of the attached claims and their equivalents. 
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